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A  DISTRIBUTED  CAIS 


Sue  LeG  r  a  nd 
So  f  Tech ,  Inc  . 


Abstract 

The  purpose  of  this  report  is  to  supply  a  framework 
for  discussion  of  distribution  issues  for  the 
Common  APSE  (Ada*  Programming  Support  Environment) 
Interface  Set  (CAIS)  design.  A  taxonomy  of  methods 
will  be  presented  .  Major  distribution  issues  will 
then  be  identified  and  various  resolutions  discus¬ 
sed.  The  designers  of  the  CAIS  will  decide  which 
functions  will  actually  be  controlled  by  the  CAIS 
model  and  which  are  to  be  implementation  dependent. 


Some  assumptions  must  be  made  for  the  purpose  of  scoping  this 
study.  U'e  assume  that  a  distributed  computing  system  is  composed 
of  computing  resources  called  elements,  and  each  element  is 
composed  of : 

At  least  one  processor  capable  of  running  a  development  task 
At  least  one  portable  tool 
A  CAIS  implementation. 


The  modular  nature  of  ,the  Ada  language  promotes  dispersed 
development  of  large  programs  among  many  experts.  A  distributed 
CAIS  provides  for  software  development  over  geographically 
dispersed  organizations  and  over  the  life  cycle  of  the  project 
and  the  development  systems.  Distribution  enhances  portability 
of  code  between  heterogeneous  systems  and  interoperability  of 
data  between  them.  That  is,  distribution  of  a  development  system 
may  be  the  ultimate  fulfillment  of  the  CAIS  model. 
Implementations  will  have  a  need 


for  -  . 


:  sa  e  n  t  c  : 


r  q  r  o  c  c 


control,  scheduling,  accountability,  availability,  fault 
tolerance  and  system  configuration  management  and  e x t e nd i b i 1 i t y . 


There  is  no  limit  to  the  amount  of  dispersion  involved,  and 
many  applications  require  that  the  units  be  located  all  over  the 
world  and  in  outer  space.  Many  military  applications  for 
command,  control  and  communication  have  been  defined.  Twenty-two 
different  kinds  of  networks  have  been  identified  so  far  for  the 
NASA  Space  Station. 

Private  industry  has  begun  to  stress  distributed  computer  systems 
as  evidenced  by  the  recent  adoption  of  Manufacturing  Automation 

*Ada  is  a  trademark  of  the  U.S.  Government,  Ada  Joint  Program 
Office  (AJPO). 
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Protocol  (MAP)  networks  by  many  companies,  [14]  These  networks 
use  the  standards  defined  by  the  International  Standards 
Organizac ion.  [12] 

The  second  version  of  CAIS,  which  is  being  produced  now  by 
SofTech,  Inc.,  treats  the  issue  of  distribution.  [7]  Charles 
Howell  at  MITRE,  Inc.  has  led  a  project  to  build  a  prototype  of  a 
distributed  CAIS  model.  [8]  Both  of  these  efforts  are  producing 
reports  which  will  be  in  the  public  domain- 


Taxonomy  of  Distributed  Systems 

A  taxonomy  must  consider  many  different  aspects  of  distribution. 
Physical  distribution  is  not  defined  in  steps,  but  in  a  broad 
spectrum  of  system  types  that  may  or  may  not  have  various 
features  and  functions.  Two  systems  may  be  comparably 
distributed  and  sophisticated  but  greatly  different.  Computer 
systems  can  be  physically  distributed  in  many  different  ways. 
The  application,  available  resources  and  space  and  budget  of  the 
users  will  impact  the  decision.  [3]  The  discussion  below 
assigns  classifications  to  the  system  configurations  upon  which  a 
CAIS  might  be  implemented. 

Uniprocessor  -  Multiprogramming 

This  shall  be  designated  Class  A.  Some  instances  of  uniproces¬ 
sors  are  often  cal  lea  distribution,  but  they  are  not  distributed 
processing.  Uniprocessors  are  mentioned  here  only  for  reference. 
Occasionally  an  office  system  is  advertised  which  provides  "dis¬ 
tributed"  data  processing  functions  over  an  entire  building. 
However,  close  examination  shows  the  system  to  be  merely  many 
terminals  all  attached  to  one  over-worked  uniprocessor.  In  this 
system,  a  single  processor  is  capable  of  multitasking  and  a 
number  of  users  time-share.  They  access  the  central  processor  on 
a  number  of  terminals  located  at  various  locations,  but  the 
terminals  are  all  wired  inco  the  same  computer.  One  processor  is 
present  and  is  responsible  for  all  tasks:  calculations,  input/ 
output  functions,  database  management,  etc. 

Multiprocessors 

This  is  class  B,  A  number  of  processors  are  located  together  on 
the  same  board,  or  at  least  on  boards  in  the  same  cabinet.  This 
is  distribution  in  the  strictest  sense,  because  the  various 
processors  cooperate,  doing  separate  and  parallel  tasks,  and  they 
communicate  through  a  medium.  This  system  may  be  very  big  and 
complex  and  capable.  All  users  still  access  this  group  of 
processors  through  the  processor  responsible  for  user  interface. 

Clusters 

This  is  class  C.  A  more  obviously  distributed  system  is  organ¬ 
ized  around  multiple  homogeneous  processing  elements,  or  enti¬ 
ties,  that  are  physically  separate  but  in  close  proximity.  Each 
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entity  has  at  least  one  processor  and  associated  software  capable 
of  performing  automated,  intelligent  functions.  These  entities 
have  different  capabilities  and  will  be  organized  on  a  functional 
and/or  geographical  basis,  but  they  cooperate  in  the  support  of 
user  requirements.  The  entities  are  connected  through  physical 
cables  (usually  high  speed),  and  one  processor  in  each  entity  is 
required  tc  handle  communication  using  the  same  protocol  as  the 
other  entities  in  the  cluster.  The  implication  is  dispersion  of 
similar  hardware  and  software.  Data  may  Mill  be  in  a  central 
location  (with  an  associated  processor)  and  accessed  through  one 
data  manager.  An  example  of  a  cluster  communication  scheme  is 
IBM's  System  Network  Architecture  (SNA). 

Local  Area  Network  (LAN) 

This  is  class  D.  The  entities  are  still  connected  by  physical 
cable,  but  they  may  not  have  the  same  capability  or  even  be 
homogeneous.  The  entities  are  usually  autonomous,  having  control 
over  their  own  domain  only.  They  communicate  through  network 
interface  units  (NIUs)  with  separate  hardware  and  software  to 
translate  the  communication  protocol  to  a  standard  protocol 
agreed  upon  and  shared  by  the  all  of  the  entities  on  the  entire 
LAN.  There  will  be  one  net  server  for  an  entire  cluster  de¬ 
scribed  above  to  share  for  net  access.  For  instance,  a  cluster 
using  SNA  may  be  on  the  same  net  as  a  VAX  cluster  using  DEC  Net. 

The  NIUs  will  be  responsible  for  translating  each  local  protocol 
to  one  that  the  entire  net  can  use.  There  are  international 
standards  for  this  which  will  be  discussed  later.  Typical 
functions  handled  by  the  NIUs  include  modem,  parallel  to  serial 
conversion,  repeater,  address  recognition,  parity  check,  token 
management,  bit  stuffing  and  error  timeouts. 

Data  is  distributed  among  the  entities,  and  there  are  various 
schemes  for  users  to  access  the  distributed  data  base.  This  and 
the  challenge  of  access  control  will  also  be  discussed  later.  A 
user  should  be  able  to  draw  upon  the  entire  collection  cf  files 
in  the  distributed  data  base  as  though  it  were  kept  locally. 

Remote  Area  Networks 

This  is  class  E.  It  is  possible  to  tie  clusters  or  even  local 
area  networks  together  and  create  remote  area  networks  (RANs). 
These  nets  are  connected  by  gateways  that  are  responsible  for  any 
differences  of  protocol  or  hardware.  There  will  be  only  one 
gateway  to  serve  an  entire  cluster  or  LAN  member  of  the  RAN. 
A  gateway  often  must  provide  high  speed  links  over  long  distances 
with  few  occurrences  of  errors. 


Advantages  of  centralized  processing  and  distributed  processing 

A  central  computer  source  offers  the  greatest  amount  of  control 
and  the  use  of  only  one  standard  protocol  for  all  users  and  all 
applications.  There  is  no  need  or  opportunity  to  duplicate 
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software  resources  or  data  bases.  There  Is  no  problem  with 
Incompatible  hardware,  since  all  components  are  extensions  of  the 
central  hardware.  Project  control,  programming  techniques  and 
configuration  control  are  easily  implemented.  Vendor  and  other 
technical  support  is  simple  and  less  expensive  than  for  systems 
with  more  than  one  computer. 

Distributed  processing  has  certain  advantages  over  a  central 
processor  or  even  a  central  computing  center.  The  most  obvious  is 
extendibility  from  a  low  cost  initial  investment.  Small, 
specialized  computers  can  be  obtained  and  then  added  to  as 
requirements  and  funds  Increase.  These  small  systems  are  easier 
to  use  and  maintain  as  well  as  less  expensive. 

Local  processing  can  be  done  with  muuh  less  delay  than  letting  all 
users  submit  jobs  through  a  central  control.  Results  can  then  be 
sent  to  a  larger  unit  for  summarizing  with  other  units'  work.  The 
result  is  also  less  data  being  transmitted.  This  is  a  form  of 
parallel  processing. 

User  control  is  often  cited  as  a  good  reason  for  distributed 
processing.  Every  user  has  critical  data  that  he  lik.es  to  have 
located  at  his  work  station.  Each  user  is  also  convinced  that 
his  choice  of  resources  is  the  best.  With  distribution,  there  is 
a  better  chance  of  giving  the  user  his  selection  of  tools. 

Distributed  backup  of  computer  resources  gives  the  added 
protection  against  loss  of  an  entire  facility.  Backup  resources 
can  be  located  far  enough  away  to  be  safe.  These  backup 
resources  can  ordinarily  be  used  to  share  Che  work  load. 


Space  Station  Requirements  and  Coals 

The  NASA  Space  Station  requires  a  complex  computer  network  of 
clusters,  LANs  and  RANs.  There  will  be  a  variety  over  time  and 
location  of  system  resources,  system  requirements  and  job 
requirements.  There  will  be  non-stop  target  systems  performing 
r. on-stop  functions.  The  hardware  and  software  of  these  target 
systems  will  need  to  be  upgraded,  expanded  and  tested  without 
bringing  them  to  a  halt.  Process  control  will  require  elaborate 
interprocess  communication  and  prioritizing.  Load  balancing  and 
synchronizing  of  tasks  will  be  sophisticated.  Resources  must  be 
managed  with  strict  access  control.  Some  resources  must  be 
shared  while  others  must  be  hidden  and  protected. 


The  Space  Station  Program  goal  of  software  maintenance  is  to  be 
independent  of  the  origination  of  the  software  and  valid  over  the 
entire  life  cycle  of  the  project  and  the  host  and  target  systems. 
The  goal  of  user  interface  is  to  have  a  common  interface  for  all 
user  groups,  resources  and  locations.  The  goal  of  accountability 
is  to  have  a  automatic  record  of  all  charges,  credits  and 
privileges  common  to  the  entire  distributed  network  and 
transparent  to  the  user. 
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CA1S  Implications 


The  CAIS  model  is  still  an  interface  between  layers,  even  when  it 
is  on  a  distributed  computer  system.  The  difference  is  that  the 
underlying  hardware  is  distributed  and  the  cools  include 
communication  software.  See  Figure  l. 


According  to  Richard  Thai  1 ,  Technical  Director  of  the  CALS  2 
development  team,  if  the  underlying  hardware  and  software  is  a 
distributed  system,  then  the  CAIS  will  provide  interfaces  t  r 
allow  development  tools  some  limited  control  of  the  distributee 
environment.  The  services  for  distributed  capabilities  must  be 
structured  so  that  tools  can  be  freely  moved  between  monolithic 
and  distributed  systems.  For  example  development  tools  imported 
from  a  monolithic  system  must  not  be  forced  to  supply  routing 
parameters  to  a  distributed  implementation;  and  tools  from  a 
distributed  implementation  must  operate  normally,  when  routing 
information  is  supplied  to  a  monolithic  system. 


The  goal  of  CAIS  2  is  to  allow  tools  to  effectively  operate  in  a 
distributed  environment  where  the  system  elements  may  not  be 
homogeneous.  This  means  that  Che  CAIS  must  supply: 


a)  a  method  of  routing  data  to  and  from  separately  identifiable 
elements  of  a  distributed  system, 


Figure  l.  Distributed  CAIS  Model 


c)  methods  for  dealing  with  a  database  which  may  or  may  not  be 

distributed  in  a  transparent  fashion,  and 

d)  a  method  oi  initiating  and  controlling  program  execution  on 

specific  remote  processors. 

To  preserve  development  tool  portability,  these  services  must  be 
constrained  to  methods  likely  to  be  useful  and  useable  in  all 
distributed  systems.  Moreover,  these  services  must  have  well 
defined  behavior  when  implemented  on  monolithic  systems. 

This  author  believes  that  the  best  way  that  CAIS  can  provide 
these  services  is  co  use  International  Standards  Organization 
(ISO)  Open  Systems  Interconnection  (OSI)  defined  communication 
tools.  If  the  tools  are  built  to  ISO  OSI  standards  and  the  CAIS 
interface  to  these  tools  is  the  same  among  implementations,  then 
the  communication  tools  will  be  portable.  Suppose  a  development 
tool  needed  a  software  module  chat  resided  on  a  remote  system. 
The  Ada  "with"  command  would  list  this  module  assuming  it  was  in 
the  local  program  library.  The  CAIS  would  call  on  the  services 
of  some  communication  tools  to  provide  the  modal,  in  a  way 
transparent  to  che  user. 

The  ISO  OSI  model 

The  ISO  OSI  model  provides  the  international  standards  for  any 
computer  system  to  be  open  to  communication  with  any  other  system 
obeying  the  same  standards,  anywhere  in  the  world.  It  consiscs 
of  a  Reference  model,  Services  and  Protocols,  each  providing  mors 
constraining  specifications  but  consistent  with  the  others. 

The  Reference  model  define  s  types  of  objects  in  the  system  and 
general  relations  among  these  types.  The  Service  Specifications 
define  in  more  detail  the  service  provided  in  each  layer.  The 
Protocol  Specification  is  the  lowest  level  of  abstraction  and 
defines  precisely  what  control  information  is  to  be  sent  and  what 
procedures  are  tc  be  used  to  interpret  this  control  information. 
It  is  the  Protocol  Specification  chat  is  of  the  most  interest, 
since  it  defines  the  cools  to  be  used  for  communication.  See 
Figure.  2 .  These  tools  will  all  need  the  support  of  the  CAIS 
services,  and  the  CAIS  may  depend  on  them  to  support  the  needs  of 
ocher  tools. 

So  far  che  ISO  model  includes  tools  specifically  for  each  layer 
and  for: 

Naming  and  Addressing 
Security 

Commitment,  Concurrency,  Recovery 
Job  Transfer  and  Manipulation 
Virtual  Terminal,  including  Graphics 
Fault  Management 
File  Access  and  Management 
Data  Descriptive  File 
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OSI  Reference  Hodel 


Flgure  2.  The  ISO  OSI  Model 

CAIS  and  Distribution 

The  issue  of  distribution  Is  straightforward  in  the  CAIS  model. 
However,  CAIS  implementations  must  consider  many  aspects  not 
shown  in  Figure  1.  The  issues  of  access,  user  transparency  and 
fault  tolerance  must  be  considered.  Communication  methods  impact 
the  kinds  of  tools  required  and  how  they  are  used.  Data  Base 
Distribution  can  be  accomplished  many  different  ways,  and  this 
also  affects  the  cools.  Processes  can  be  distributed  over  the 
physical  network  according  to  different  rules.  The 
interconnection  control  can  be  tight  or  loose  coupling.  The 
exchanges  between  various  host  and  various  target  environments 
require  different  tools  and  different  protocols.  Each  of  these 
aspects  affects  the  way  the  tools  will  interface  with  a  system. 

The  following  are  discussions  of  possible  communication 
implementation  features  that  try  to  provide  for  the  above  needs. 
Each  of  these  are  implemented  in  tools  that  provide  and  require 
special  services  of  the  CAIS  2. 

Agents 

Agent  tools  are  required  to  act  on  behalf  of  processes  located  on 
other  systems.  Suppose  a  process  running  on  a  system  in  New  York 
needs  the  service  of  an  array  processor  in  Houston.  There  must 
be  an  agent  on  the  New  York  system  to  work  with  an  agent  on  the 
Houston  system  to  coordinate  the  distributed  processing.  Agents 
are  also  needed  for  file  transfer. 


Network  Integrity 


Tools  are  needed  to  monitor  and  report  network,  system  health  and 
status.  They  will  consolidate  reports  and  provide  them  to  the 
network  administrator  at  each  location.  They  will  need  reports 
from  the  CAIS  2  services. 

Account  lag 

There  is  often  a  requirement  for  reporting  use  of  the  network,  for 
accounting.  Accounting  tools  must  record  which  processes  from 
which  systems  used  the  network  and  for  what  purposes  and  for  how 
long.  These  tools  will  need  reports  from  the  CAIS  services. 

User  Interface 

Tools  must  exist  to  provide  a  friendly  user  interface  and  hide 
the  mechanics  of  distribution.  The  CAIS  model  must  provide  the 
interface  between  these  user  features  and  the  distributed 
operating  system. 

Access  Control 

Access  control  involves  the  usual  security  considerations.  In  a 
distributed  environment  it  also  involves  considerations  of  the 
various  capabilities  of  the  systems  and  how  they  are 
implemented.  [41  The  ISO  OSI  provides  procedures  for  access 
control  . 

Fault  Tolerance 

Tools  that  provide  fault  avoidance  will  need  CAIS  services  to 
help  with  such  things  as  error  correction.  Fault  tolerance 
tools,  on  the  other  hand,  will  require  services  to  help  locate 
the  backup  element,  bring  the  backups  on  line  and  synchronize  the 
new  participat  on.  The  CAIS  will  provide  these  services  or  in 
turn  rely  on  other  tools. 

Communication  Connections 

The  type  of  connection  between  elements  of  the  network  will 
dictate  the  use  of  particular  tools.  In  addition  to  the 
consideration  of  synchronous  or  asynchronous  transmission,  the 
system  may  use  a  number  of  different  connections. 

Point-to-point  connections  allow  two  and  only  two  elements  to 
talk  directly  with  each  other.  Elaborate  switching  mechanisms 
are  required  with  associated  software  tools.  These  tools  will 
need  the  help  of  CAIS  services  to  help  identify  the  location  or 
the  elements,  to  assist  the  switching  mechanism,  and  to 
sychronize  the  switching. 

Store-and-f orward  connections  depend  on  each  element  to  receive 
all  messages  and  send  them  on  to  the  their  destination.  Each 
kind  of  mechanism  to  accomplish  this  must  have  an  associated 
device  driver.  Tools  are  needed  ro  aid  message  sending 
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synchronization  and  to  aid  in  identifying  which  messages  to  copy 
as  they  are  passed  and  how  to  route  new  messages.  The  CAIS  oust 
see  that  these  services  are  provided  and  coordinated. 

Broadcast  connections  allow  all  elements  to  listen  to  all 
messages.  Tools  for  this  oroadcast  method  will  also  require 
services  provided  by  or  obtained  through  the  CAIS. 

Message  Handling 

Modern  networks  send  messages  in  packets.  These  packets  are 
usually  of  uniform  size  and  are  preceded  and  followed  by  code 
that  delimits  them  and  assists  in  their  handling.  There  are 
various  ways  to  send  these  packets.  A  datagram  is  a  message  sent 
from  the  source  to  the  destination  one  way,  one  time  with  no 
acknowledgement.  It  is  good  for  very  high  speed  connections  that 
do  not  require  a  high  degree  of  accuracy.  Telephone  messages  are 
sent  this  way. 

A  virtual  circuit  appears  to  the  user  to  be  a  point-to-point 
connection.  Each  packet  is  acknowledged  from  the  receiver  as  it 
arrives.  Some  acknowledgements  include  code  cnecking  data. 

The  International  Standards  Organization  (ISO)  Open  Systems 
Interconnection  (OSI)  model  contains  tools  already  defined  for 
message  handling.  The  CAIS  must  be  che  interface  between  these 
tools  and  the  operating  system  and  other  tools. 

Data  Base  Distribution 

Traditionally  data  bases  were  considered  in  terms  of  shared  files 
or  distributed  data.  In  a  distributed  system,  both  conditions 
exist  at  the  same  time.  It  is  common  t*o  store  a  back  up  file 
copy  at  a  remote  node  of  the  network  under  the  control  of  another 
system  with  a  different  file  structure.  This  copy  will  then  need 
to  be  accessed  and  kept  updated  just  as  the  original  copy.  File 
transfers  must  also  be  supported.  Intertask  allocation  of  shared 
files  becomes  more  complicated  in  a  distributed  system.  The 
tools  to  handle  the  data  base  management  will  depend  on  gate 
keeping  provided  by  the  CAIS. 

Distributed  Processing 

Tools  will  be  needed  to  start,  stop,  monitor  and  control 
processes  distributed  in  other  systems.  Other  tools  will  be 
needed  to  cooperate  with  remote  systems  upon  which  jobs  are 
initiated  that  require  local  support  of  distributed  processing. 
This  is  in  addition  to  the  remote  access  to  resources  such  as 
files  and  array  processors.  Some  tools  for  this  feature  are 
being  defined  by  the  ISO.  Others  will  be  needed  and  all  will 
require  CALS  services. 

Interconnection 

Tools  will  be  necessary  to  manage  the  interconnection  of  the 
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communicating  systems.  They  may  use  tight  or  loose  coupling. 
Tight  coupling  provides  for  a  master  and  slave.  It  is  often 
used  when  a  number  of  intelligent  terminals  are  tied  to  a  central 
main  frame.  Each  station  may  work  independently,  but  all 
communication  between  them  is  tightly  controlled  by  the  main 
frame.  Tools  chat  facilitate  this  will  need  gate  keeping 
services  from  the  CAIS. 

Loose  coupling  exists  between  completely  autonomous  systems. 
Communication  occurs  as  a  result  of  cooperation  between  the 
systems.  The  OSI  provides  for  various  states  of  this 
communication  and  provides  the  protocols  and  parameters  needed. 
Tools  involved  in  this  type  of  interconnection  will  need  the 
support  of  the  CAIS  services. 

Virtual  Terminal 

In  a  distributed  system  there  is  often  the  requirement  for  a  user 
to  sit  at  a  terminal  In  one  location  and  access  a  system  in 
another  location  as  if  his  terminal  was  connected  to  it.  A  tool 
will  be  needed  to  work  with  the  CAIS  services  in  both  systems  to 
make  this  happen. 

Host-Target  Interface 

Tools  will  be  needed  to  provide  the  interface  of  hosts  and 
targets.  They  will  be  needed  for  monitoring,  debugging,  and 
upgrading  resources  developed  on  the  host  for  the  target 
environment  and  the  run  time  support  for  these  resources. 

The  NATO  Interface  Set 

The  Nunn  Amendment  Special  Working  Group  (SWG)  on  APSEs  has  a 
goal  of  defining  a  standard  interface  based  on  the  CAIS  model  and 
using  important  contributions  from  the  Portable  Common  Tool 
Environment  (PCTE).  This  is  an  exciting  concept,  because 
development  of  the  two  models  has  concentrated  on  complimenting 
areas  of  concern.  For  instance,  the  CAIS  model  defines  services 
of  the  KAPSE  and  is  concerned  with  security.  The  PCTE  model  uses 
schemes  and  has  begun  treating  the  issues  concerning 
distribution. 

Representatives  from  both  groups  have  been  studying  the 
similarities  and  differences.  Other  interested  people  have  been 
tracking  the  progress  of  both  groups  hoping  for  contributions  to 
the  design  of  important  projects.  Dr.  Charles  McKay,  of  the 
University  of  Houston  at  Clear  Lake  recently  sent  constructive 
comments  to  both  groups  from  the  perspective  of  the  NASA  Space 
Station  needs.  Herra  Fiscner,  lead  author  of  "A  View  of  the  CAIS 
from  Industry  and  Academia",  has  worked  closely  with 
representatives  from  the  group  creating  the  PCTE. 

If  the  NATO  Interface  Set  incorporates  facilities  for  a 
distributed  CAIS  and  is  accomplished  in  a  timely  manner,  it  may 
be  one  of  the  most  important  contributions  to  the  Ada  community. 
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Extending  the  Granularity  of  Representation 
and  Control  for  the  MIL-STD  CAIS  1.0  Hod*  Model 
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Introduction 

The  Common  APSE  (Adal  program  Support  Environment) 
Interface  Set  (CAIS)  (DoD85]  node  model  provides  an 
excellent  baseline  for  interfaces  in  a  single-host 
development  environment  (see  Figure  l)  .  To  encompass 
the  entire  spectrum  of  computing,  however,  the  CAIS 
model  should  be  extended  in  four  areas.  It  should 
provide  the  interface  between  the  engineering 
workstation  and  the  host  system  throughout  the  entire 
lifecycle  of  the  system.  It  should  provide  a  basis  for 
communication  and  integration  functions  needed  by 
distributed  host  environments.  It  should  provide  common 
interfaces  for  communication  mechanisms  to  and  among 
target  processors.  It  should  provide  facilities  for 
integration,  validation,  and  verification  of  test  beds 
extending  to  distributed  systems  on  geographically 
separate  processors  with  heterogeneous  instruction  set 
architectures  (ISAs).  This  paper  proposes  additions  to 
the  PROCESS  NODE  model  to  extend  the  CAIS  into  these 
four  areas. 2 


Rationale 

The  intent  of  the  CAIS  is  to  promote 
transportability  and  interoperability.  The  user 
interface  should  provide  the  same  view  ot  the  system 
for  a  remote  workstation  connected  through  a  network  as 
for  a  directly  connected  terminal.  Accessibility  and 
finer  granularity  of  the  PROCESS  NODE  and  QUEUE  file 
information  could  provide  processor  performance 
measures  during  the  design  phase  of  the  project, 
debugging  information  during  the  coding  phase,  and 
assessments  of  hardware  and  software  changes  during  the 


1  Ada  is  a  registered  trademark  of  the  U.S.  Government, 
Ada  Joint  Program  Office  (AJPO) . 

2  it  is  the  intent  of  this  paper  to  discuss  some  of  the 
topics  which  were  explicitly  deferred  in  MIL-STD  CAIS  1.0. 
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maintenance  phase. 

CAIS-provided  code  and  data  sharing  could  provide 
services  (and  entities)  in  a  cost-effective  manner  to 
more  than  one  application  or  user.  To  implement 
sharing,  the  node  model  must  be  able  to  manage  data  for 
dictionary  driven  processes,  maintain  version  and 
revision  information  for  library  units,  and  provide 
security  to  maintain  the  integrity  of  the  system.  Data 
management  requires  information  such  as  location, 
format,  and  access  control  of  sharable  resources.  It 
might  also  extend  to  "knowledge"  regarding  the  use  of 
data,  so  that  data  may  be  relocated  to  facilitate 
convenient  access.  PROCESS  NODES  should  be  able  to  take, 
advantage  of  code  (such  as  common  packages)  that  can  be 
sh?  red. j 

The  PROCESS  NODE  model  should  accommodate  the 
communications  necessary  in  a  distributed  environment. 
Five  types  of  communication  interfaces  should  be  added 
to  the  current  model:  communication  between  parts  of  a 
process  executing  on  separate  processors,  between 
processors  (extending  to  processors  with  different 
ISAs) ,  between  the  CAIS  and  the  PROCESS  (in  both  the 
host  and  the  target  environment) ,  between  different 
CAIS  implementations,  and  among  PROCESS  NODES,  In  order 
to  satisfy  the  Ada  Language  Reference  Manual  (LRM83] 
requirement  that  "several  physical  processors  (may) 
implement  a  single  logical  processor"*  effective 
information  interchange  is  vital.  Information  must  be 
communicated  in  an  understandable  format  between 
heterogeneous  ISAs.  "Hooks"  should  be  established  so 
that  individual  elements  of  a  test  bed,  as  well  as  the 
integrated  test  bed,  can  be  monitored.  The  CAIS  should 
be  extended  to  interact  with  other  CAIS 


3  Multiple  copies  of  packages,  such  as  TEXT_IO,  would 
be  eliminated  in  favor  of  all  processors  at  a  site 
accessing  the  same  copy.  In  a  heterogeneous  distributed 
environment,  this  can  extend  to  shared  copies  of  SYSTEM 
packages  and  STANDARD  packages,  if  a  common  data 
representation  scheme  is  used. 

*  Ada  Language  Reference  Manual,  Chapter  9,  paragraph 
5. 
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implementations .  5  when  processes  executing  under  the 
auspices  of  two  different  CATS  implementations  interact 
and  require  CAIS  services,  a  standard  method  should  be 
used  to  determine  which  CAIS  should  be  called. 
Interfacing  to  communication  mechanisms,  especially  in 
a  geographically  separate  system,  is  an  important 
aspect  of  the  CAIS. 

Annotations  for  *non-functional"6  directives  could 
be  handled  by  the  PROCESS  NODE  model.  These  directives 
include  desired  degree  of  f ault-tolerance,  scheduling 
priority,  desired  level  of  status  information,  recovery 
processes,  performance  measures,  special  hardware 
requirements,  and/cr  amount  (and  detail)  of  information 
to  be  promoted.  Fault  tolerance  could  be  supported  to 
ensure  that  sufficient  resources  are  utilized  to 
maintain  the  level  of  integrity  required  by  the 
process.  Scheduling  of  processes  according  to 
priorities  should  be  considered.:  algorithms  for  serving 
processes  according  to  their  priorities  could  be 
provided  in  a  straightforward  manner.  Directives 
stating  the  granularity  of  information  required  for  a 
PROCESS  (which  determines  thi  amount  of  overhead 
incurred)  should  be  flexible.7  Directives  should  also 
provide  error  recovery  and  rollback  to  the  last  "safe" 
state  at  a  level  of  overhead  which  is  appropriate  for 
the  PROCESS.  Performance  measures  should  be  provided, 
especially  for  "time  critical"  processes  which  may  need 
to  be  routed  to  a  processor  based  on  the  speed  and 
level  of  services  available.  The  need  to  know  the 
execution  efficiency  of  processes  on  target  processors 
is  a  major  reason  the  CAIS  services  should  be  available 
in  the  target  environment.  In  some  configurations, 


5  Oberndorf,  Patricia,  Prototyping  CAIS  [Obern86] . 


6  "Non-functional"  is  used  here  to  denote  constraints 
on  functionality  beyond  those  which  are  explicitly  written 
into  the  code. 

7  For  example,  information  pertaining  to  the 
current/last  instruction  or  procedure  executing  might  be 
requested.  In  the  same  way,  the  status  of  entities 
ranging  from  register  values  to  values  of  user  variables 
might  also  be  requested. 
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PROCESS  NODES  for  each 
thread  of  control 


F I CURB  2 

Snapshot  of  four  PROCESS  NODES 
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security  will  be  important;  security  directives  should 
be  provided  and  enforceable  [LeGra86] .  The  CMS  can  be 
continually  extended  by  providing  additional  handlers 
to  accommodate  future  "non-functional“  directives. 

The  PROCESS  NOD/5  model  should  include  capabilities 
to  query  and  to  negotiate  with  other  nodes.  Negotiation 
may  be  required  in  the  case  of  a  remote  procedure 
(subprogram)  call  where  the  size  of  the  parameters 
exceeds  the  capabilities  of  the  receiving  processor. 
Query  and  negotiation  procedures  could  detect  this 
problem  and  establish  a  piecewise  transmission  of  data. 
Processes  executing  on  processors  with  different  ISAs 
could  negotiate  a  standard  data  format  for  transmitting 
data.  Query  capabilities  are  vital  for  processes  which 
have  very  specific  processor  needs.  Query  and 
negotiation  capabilities  should  be  provided  to 
determine  the  optimal  processor  configuration  to 
execute  a  process.  Library  management,  in  a  system 
containing  heterogeneous  ISAs  and  specialized 
processors,  creates  demand  for  information  such  as 
version/revision,  intended  ISA,  special  processing 
needs  or  priorities,  and  other  required  support. ®  Check 
out,  with  locking  mechanisms,  must  be  maintained  for 
library  units.  Security  Cor  the  items  being  managed  is 
also  a  concern.  The  level  of  access  required  to  read  or 
update  information  must  be  established,  including 
altering  access  requirements  after  updates.  Creation 
and  maintenance  of  multiple  copies  must  be  addressed 
with  respect  to  update®  procedures, 


Recomaaendations 

The  current  CAIS  node  model  should  be  enhanced  in 
four  ways.  First,  the  PROCESS  NODE  state  information 
should  be  more  descriptive.  Second,  there  should  be  a 
PROCESS  NODE  representation  of  the  status  of  each 


®  Other  support  may  include  speed,  space,  and/or 
security  requirements,  etc. 

®  Update  is  being  used  here  to  encompass 
all  modification  functions,  addition,  modification, 
deletion,  etc. 
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Snapshot  of  four  PROCESS  MODES 


Extending  the  Granularity  of  Representation 
and  Control  for  the  MIL-STD  CAIS  1.0  Mode  Model 


thread  of  control  extending  to  any  level  of 
decomposition,  and  a  QUEUE  associated  with  each 
PROCESS  NODE.  Third,  the  QUEUE  NODE 10  should  be  able  to 
provide  accessible  status  measures  beyond  these  which 
are  "hard  coded"  into  the  process.  Finally,  the  QUEUE 
NODE  model  should  provide  capabilities  to  act  on  the 
information  received. 


As  an  example  of  the  implications  of  the  above 
recommendations,  consider  a  PROCESS  that  spawns  three 
subordinate  tasks:  a  producer,  a  buffer,  and  a 
consumer.  Figure  2  is  a  snapshot  of  the  four  PROCESS 
NODES;  it  represents  the  state  of  each  thread  of 
control  currently  executing  on  behalf  of  the  "main" 
process.  The  overall  job,  as  well  as  each  subordinate 
task  is  depicted  as  a  PROCESS  NODE,  with  an  associated 
QUEUE  NODE.  Each  PROCESS  NODE  has  several  predefined 
attributes  including:  CURRENT_STATUS ,  PARAMETERS,  and 
RESULTS.  Other  information,  such  as  the  logical  name  of 
the  site  where  the  process  is  executing,  may  also  be 

~  _  u  rvnrnc*  vmnr 
at,  u  wwwjm  a 


*  ••  •  *  1  »  v.  1  ^ 
a v  a  ^  aau  xc i 


r\  r?T?rir*  linnr  v  i  n  nno  n  f  fha 

.  11WW4W  4  WWM  V  w»«w  —  ““  - — 


subordinate  tasks  has  a  relationship  to  the  QUEUE  NODE 
associated  with  the  PROCESS  NODE  for  the  overall  job. 
Note  that  when  the  subordinate  tasks  terminate,  their 
respective  PROCESS  and  QUEUE  NODES  cease  to  exist. 


In  order  to  augment  the  PROCESS  NODE,  the  process 
states  should  consist  of  "meta-states"  as  well  as 
"micro-states".  In  addition  to  the  current  "meta¬ 
states"  READY,  SUSPENDED,  ABORTED,  and  TERMINATED,  a 
new  meta-state,  RUNNING,  should  be  added.  The 
meta-states  should  also  have  micro-states  to  provide 
additional  information.  The  READY  meta-state  should 
include  the  micro-states  WAITING  (for  resources), 
COMPLETE  (but  not  terminated),  and  BLOCKED  (awaiting 
rendezvous) .  The  TERMINATED  meta-state  should  include 
the  micro-states  NORMAL  and  ABNORMAL. 


To  increase  the  granularity  of  the  PROCESS  model, 
the  PROCESS  NODE,  which  represents  the  overall  job 
should  also  provide  PROCESS  NODES  for  each  "thread  of 
control".  That  is,  a  PROCESS  NODE  should  be  associated 
with  every  body  of  a  subprogram,  task,  or  package  in  a 
state  of  execution.  All  PROCESS  NODES  should  be  of  the 


10  The  term  QUEUE  NODE  is  used  (rather  than  QUEUE  FILE) 
in  order  to  describe  the  QUEUE  as  an  entity. 
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same  form  (complete  with  proposed  extensions)  .  11  The 
PROCESS  NOOE  for  each  thread  of  control  should  have  an 
associated  QUEUE  NODE.  Information  from  QUEUE  NODES 
should  be  promotable  upward  to  the  QUEUE  NODE 
representing  the  next  higher  level  of  decomposition, 
based  on  the  amount  of  information  required  by  the 
higher  level  PROCESS/QUEUE  pair.  In  this  way,  the 
current  CAIS  PROCESS  NODE  is  maintained  on  the  job 
level,  but  is  also  decomposable  to  provide  more 
specific  information  when  needed. 

Status  information  provided  to  the  QUEUE12  should 
be  usable  by  other  processes.  In  the  current  model, 
data,  procedures,  or  tasks  in  one  process  cannot  be 
directly  referenced  from  another  process. 13  queue  files 
ate  currently  used  as  holders  of  PROCESS 
information. 14  The  level  of  detail  for  status  messages 
and  the  amount  of  overhead  incurred,  should  be  able  to 
be  specified.  Other  specifiable  information  includes 
the  amount  of  information  that  should  be  promoted  from 
a  QUEUE  NODE  at  any  level  to  a  QUEUE  node  related  to  a 
PROCESS  at  a  higher  level.  Extensibility  of  the  QUEUE 
NODE  model  can  be  provided  by  viewing  the  node  as  a 
database  which  can  be  queried  by  applications  (or 
engineers).  Additional  information  could  be  added  to 
the  database  in  the  future,  which  could  be  utilized  by 
processes  which  are  aware  of  the  enhancements.  Status 
information  generated  independent  of  the  process  (or 
processor)  is  necessary  in  a  distributed  system,  in  the 
event  of  process  (or  processor)  failure. 

The  QUEUE  should  be  mors  than  a  passive 
information  receptacle.  It  should  be  capable  of  being 
used  to  initiate  procedures,  such  as  recovery  upon 


11  The  PROCESS  NODES  should  extend  to  any 
level  of  decomposition  necessary. 


12  CAIS  Rationale  and  Criteria  document. 

13  MIL-STD  CAIS  1.0  p.  14. 

14  Three  types  of  QUEUE  files  are  defined.  The  QUEUE 
files  can  operate  in  SOLO  (write  append,  destructive  read), 
COPY  (SOLO  QUEUE  with  initial  contents)  ,  and  MIMIC 
(dependent  upon  another  QUEUE  file)  modes. 
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used  to  initiate  procedures,  such  as  recovery  upon 
detection  of  a  fault  in  the  system.  Facilities  such  as 
those  necessary  to  terminate  processes  which  are  not 
performing  correctly  could  also  be  provided.  Early 
warning  regarding  process  failure  (rather  than  fault 
detection  upon  request  for  service)  provides  the 
calling  process  with  a  potentially  greater  number  of 
recovery  possibilities.  Action  in  the  event  of  failing 
processes  is  essential  in  environments  which  require 
fault  tolerance,  especially  in  unattended  systems  or  in 
those  systems  where  life  and  property  depend  on 
continuous,  correct  functioning  of  hardware  and 
software. 


Conclusion 


The  potentially  long  lifetime  and  large  number  of 
host  development  environments  and  target  processor 
configurations,  using  Ada,  require  a  CAIS  that  promotes 
transportability,  interoperability,  communication,  and 
extensibility.  The  CAIS  should  provide  a  constant  view 
(at  an  appropriate  level  of  detail)  of  the  supporting 
hardware  and  the  APSE  tools.  This  view  should  be 
provided  to  an  engineer  at  a  workstation,  as  well  as  to 


a  secure,  f ault-tolerant  distributed  process.  The  CAIS 
should  be  extended  to  provide  query  and  negotiation 
capabilities  among  nodes.  It  should  include  mechanisms 
for  handling  "non-f unct ional"  directives  (in  order  to 
address  the  spectrum  of  processing  complexity).  It 
should  also  accommodate  sharing  code  ar.d  data,  as  well 
as  communication  interfaces.  These  enhancements  are 


necessary  to  accommodate  the  potential  changes  that 
will  occur  throughout  the  lifecycle  of  Ada 
applications.  Some  extensions  to  the  CAIS  model  are 


necessary.  Recommendations  include  maintaining  more 
descriptive  PROCESS  state  information;  viewing  the 
current  PROCESS  NODE  model  as  a  description  at  the 
overall  job  level  (and  providing  PROCESS  nodes  for 
subprograms,  tasks,  and  packages,  while  they  possess  a 
thread  of  control);  viewing  the  QUEUE  as  a  resource 
NODE  rather  than  a  logging  file,  and  enhancing  the 
QUEUE  NODE  to  make  it  responsive  to  processing 


requirements.  The  proposed  extensions  to  the  CAIS  model 
maintain  the  job  level  view  of  the  original  CAIS  design 
and  enhance  it  by  providing  decomposition  to  a  finer 
level  of  granularity. 
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A  HOST  AND  TARGET  MUST  ALSO  BE  CONSIDERED  IN  EARLY  CAIS 


An  Interim  Progreso  Repoet 
on 

"A  Study  to  Identify  Tools  Needed  to  Extend  the  Minimal  Toolset  of 
the  Ada*  Frog  reaming  Support  Environment  (MAPSE)  to  Support  the 
Life  Cycle  of  Large,  Complex e  Distributed  Systems  Such  As  the 
Space  Station  Program8 

Task  Ut  *r  No.  tJEJSC  Bll 

Contract  No.  NAS  9-17010 


Team  Leader:  Charles  McKay, 

UHCL  High  Technologies  Laboratory 

Team  Members:  Robert  Charette,  SofTech 
David  Auty,  SofTech 


*  Ada  is  a  registered  trademark  of  the  Ada  Joint  Program  Office 
and  U,S.  Government 
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2.0  Relevant  Issues  and  Assumptions 

It  is  the  professional  opinion  of  the  team  leader  that  each 
of  the  following  issues  and  assumptions  offers  the  potential 
to: 

o  lower  the  life  cycle  costs  of  the  SSE  and 
the  SSP  software 

o  lower  the  life  cycle  risks  associated  with 
this  software 

o  improve  the  quality  of  this  software  and 
the  productivity  of  those  who  produce  and 
maintain  it 

o  improve  the  state-of-the-practice  of  free  world 
software  technology  and  thus  increase  the  free  world's 
return-on-investment  in  the  Space  Station  Program. 

This  opinion  is  that  of  Dr.  McKay  and  should  not  be 
interpreted  as  reflecting  positions  by  the  University  or 
SofTech  or  by  Dr.  McKay's  teammates  at  SofTech  or  the 
University. 

2.1  The  Ada  programming  language  will  serve  as  the  cornerstone 
for  developing  software  for  the  SSP. 

Elaboration: 

Of  all  the  languages  which  are  currently  available  as 
either  ah  ANSI  or  an  ISO  standard,  Ada  is: 

o  technically  superior  in  the  support  of 
modern  software  engineering  principles 

o  economically  and  politically  superior  in  its 
potential  to  leverage  free  world  advancements 
in  software  engineering  during  the  development 
cycle  of  the  SSP, 

2.2  The  MAPSE  is  the  most  appropriate  beginning  point  for 
extending  a  minimal  toolset  for  a  development  environment 
into  a  highly  automated  SSE  for  the  life  cycle  of  the  SSP. 

Elaboration: 

The  KAPSE  (Kernel  for  the  APSE)  provides  an  interface  to 
a  virtual  Ada  host  computer  with  an  underlying  project 
object  base.  Above  the  KAPSE,  six  host-independent 
functions  are  provided  : 

a  compiler,  an  editor,  a  command  language,  a 
linking  loader,  a  debugging  tool  suite  and  a 
configuration  management  capability. 
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2.3  Models  which: 


o  complement  the  Ada  culture  (ie,  the  Ada  language  &.»~ 
the  software  engineering  goals  and  principles  upon 
which  it  is  are  based) 

o  are  technically  superior  to  currently  competing  models 

o  are  politically  and  economically  viable  to  leverage 
over  both  the  near  and  long  terma> should  be  adopted 
K- - “and  exploited.  These  include  the  following : 

a)  the  Enti ty-Attr ibute/Relationship-Attr ibute 
(EA/RA)  model 

b)  the  Integrated  Model  for  programming  support 
environments 

c)  the  Open  Systems  Interconnection  (OSI)  model 
for  interconnecting  distributed  hosts  and 
targets  within  the  integrated  software  support 
environment 

Elaboration: 

The  comparatively  rapid  growth  in  the  use  of  the  EA/RA 
(also  called  "ERA")  model  as  reported  on  several 
successful  projects  is  due  to  both  its  simplicity  and 
its  power.  Its  elegance  is  also  visible  in  its  proven 
ability  to  subsume  and  support  the  earlier  data  base 
models:  hxerarcnicaxf  and  rexatxcnal. 
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The  Integrated  Model  for  programming  support  environments 
addresses  large,  complex  systems  by  dividing  life  cycle  concerns 
into  three  interrelated  sets  (processes,  products  and 
professional)  and  then  by  addressing  them  from  two  life  cycle 
perspectives  (activities  ?nd  phases).  (Definitions  and  further 
elaboration  are  given  in  section  3.0  of  this  report.) 

The  Integrated  Model  then  allows  complementary  methodologies  and 
tools  to  be  assembled  to  provide  complete  and  consistent  support 
of  software  engineering  throughout  the  project's  life  cycle.  The 
method  of  integration  is  achieved  via  a  persistent  model  of  the 
“life  cycle  project  object  base".  By  contrast,  the  Open  Model  for 
programming  support  environments  (PSE's)  allows  the  assembly  of 
off-the-shelf  components,  tools,  and  tools  sets  from  a  variety  of 
sources  without  requiring  the  collection  to  provide  or  supports 

o  a  model  of  the  life  cycle 

o  complementary  methodologies  and  tools 

o  complete  and  consistent  support  of  Software  Engineering 
throughout  the  life  cycle 

o  integration  via  a  persistent  model  of  the  life  cycle 
project  object  base 

The  Open  Systems  Interconnection  model  (not  to  be  confused  with 
the  Open  system  model  for  PSE's  described  above)  provides  a 
network  of  virtual  services  to  be  superimposed  over  a  distributed 
collection  of  heterogeneous  computing  resources.  Tnese  services 
can  (and  should)  be  part  of  an  integrated  model  of  an  SSE. 


2.4  Standards  and  draft  standards  which  : 

o  complement  the  Ada  culture 

o  are  technically  superior  to  currently 
competing  standards 
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o  are  politically  and  economically  viable  to 

leverage  ov»f  both  the  near  and  lone  tetras>should  be 
adopted “and  axploited*  These  include  the  following; 

a)  ANSI/MIL  STD  1815A  (the  Ada  language) 

b)  DIANA  (draft  proposal)  (Descriptive  Intermediate 
Attributed  Notation  for  Ada) 

c)  IRDS  (draft  proposal)  (Information  Resources 
Dictionary  System) 

d)  CAIS  (draft  proposal)  (Common  APSE  Interface 
Set) 

e)  ISO  Standards  for  the  OSI  Model  (standards  for 
lower  levels,  draft  standards  for  upper  levels) 

f)  DoO  STD  2167  (approved  standard  for  life  cycle 
documentation) 

g)  DoD  STD  2168  (draft  standards  for  life  cycle 
quality  assurance) 


Elaboration: 

In  several  other  reports  to  NASA,  the  team  leader  has 
recommended  (ard  explained  the  rationale  for)  items  a)  , 
b)  ,  d)  and  e)  .  Therefore  this  elaboration  will  be 
confined  to  c)  IRDS,  f)  2167,  and  g)  2168. 

Every  large,  complex  system  is  likely  to  be  subdivided  into 
several  major  subsystems  and  components  which  evolve  over 
time.  Typically  these  major  subsystems  and  components  benefit  from 
a  schema  (defining  structure)  and  a  dictionary  (defining 
elements)  .  Both  defining  entities  may-be/ohould-be  described  via 
the  EA/RA  model.  (See  assumption  2.3.) 

There  are  obvious  advantages  to  a  standard,  self-describing 
structure  (which  is  extensible  by  a  set  of  rules  prescribed  within 
the  standard)  for  both  the  schema  and  the  dictionary .  (For 
example,  such  structures  would  fac FlTtate  information  exchanges 
within  upward  compatible  system  evolutions  and  among  heterogeneous 
systems. )  The  IRDS  supports  the  application  of  the  EA/RA  model  to 
such  structures. 
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A  major  portion  of  the  expense  and  the  errors  in  the  life 
cycle  of  today's  systems  can  be  attributed  to 
documentation.  DoD-STD-2167  defines  a  life  cycle  model  and  the 
doc  u  me  nt a  t i on  required  for  the  associated  phases  and 
ac  t ivTti e  s .  1 1  also  defines  the  rules  for  tailoring  and/or 
extending  the  standard  to  apply  it  to  a  particular  application.  In 
short,  it  is  intended  tot 

o  reduce  the  quantity  of  required  documentation 

o  increase  both  the  quality  and  the  useability  of  the 
documentation  that  is  required 

o  increase  the  automated  support  of  both  technical  and 
management  functions  within  an  integrated  environment 

Properly  viewed,  this  is  a  subset  of  the  broader  issue  of 
reuseable  components  and  is  a  major  factor  in  advancing  the 
benefits  of  Software  Engineering. 


Craft  Dod-STD-2168  is  closely  related  to  the  already  approved 
(within  DoD)  2167.  Since  true  quality  assurance  is  possible  only 
when  there  are  standards,  guidelines  and  practices  to  measure 
against,  and  since  the  ooservable  (ie,  quantifiably  measurable) 
outputs  of  each  life  cycle  phase  are  defined  in  its  2167-required 
documentation,  this  is  a  natural  complement  to  the  documentation 
standards. 

Because  of  the  well-defined  standards  (which  are  not  subject 
to  requests  for  waivers  on  future  projects)  ,  automated  tool 
support  will  be  added  to  the  MAPSE  to  facilitate  the  generation 
and  continued  adaptation  of  documentation  generation  and  quality 
management  a  la'  2167  and  2168. 


2.5  Both  the  object  code  produced  by  the  SSE  and  the  interactive 
command  language  between  the  host  and  the  target  environments 
should  be  based  upon  a  catalog  of  standard  interface  features 
and  options  for  the  runtime  support  environment  of  a  virtual 
Ada  machine. 

Elaboration: 

The  distributed  target  environment  for  the  SSP  evolves 
over  30  years  and  has  an  indefinite  period  of 
operation.  Furthermore,  it  encompasses  processing 
resources  on  the  ground,  in  low  Earth  orbit,  in  higher 
orbits  and  extending  to  the  Moon.  A  standard  interface 
set  permits  the  software  to  be  cost  effective  in  meeting 
the  needs  of  the  application  and  to  support  processing 
which  is  safe  and  reliable  with  a  heterogeneous 
collection  of  processors. 
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2*6  All  objects  and  tools  which  are  under  configuration  control 
within  the  SSE  should  be  strongly  typed.  (As  soon  as 
possible,  if  not  initially.) 

Elaboration; 

The  benefits  of  strongly  typed  languages  for  building 
and  maintaining  reliable  software  are  well 
documented.  However  this  issue  addresses  the  extension 
of  those  benefits  throughout  the  life  cycle  support 
environment.  For  example,  a  set  of  requirements  produced 
during  the  requirements  analysis  phase  and  currently 
under  configuration  control  in  the  project  object  base 
should  be  under  access  control  not  only  by  personnel, 
but  also  by  tool.  In  other  words,  for  each  object, 
there  are  known  attributes  and  operations  associated 
with  its  type.  For  a  large,  complex,  evolving  system 
such  as  the  SSP,  this  strong  typing  can  help  prevent 
inadvertant  or  unauthorized  creation,  destruction  or 
pollution  of  the  object  base.  The  proper  use  of  the  IRD5 
(described  in  2.4)  should  greatly  facilitate  the 
implementation  of  such  environments. 
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2.7  Most  tools  beyond  the  MAPSE  should  be  methodologv-based  and 
should  have  a  clear  and  consistent  relationship  to  specific 
phases  and/or  activities  of  the  life  cycle.  (A  model  is 
provided  in  section  4.0.)  Formal  interfaces  should  be  defined 
for  each  software  engineering  activity  and  its  supporting 
tools. 

Elaboration: 

The  establishment  of  formal  interfaces  for  each  activity 
and  its  supporting  tools  permits  retaining  the  benefits 
of  evolving  a  comprehensive  and  consistent  support 
environment  (ie,  an  integrated  environment)  while 
importing  the  most  important  benefit  of  the  open 
environment?  ie,  tools  can  be  imported  to  support 
multiple  methodologies  for  a  given  phase  or  activity  as 
long  as  the  formal  interfaces  are  maintained. 

2.8  Guidelines,  methodologies  and  tool  support  to  promote  the 
development,  importation,  and  application  of  reusable 
components  should  be  a  pervasive  emphasis  throughout  all 
phases  and  activities  of  the  life  cycle  of  large,  complex, 
distributed  systems. 

Elaboration: 

Reusable  components  refer  to  any  product  of  software 
engineering  which  can,  with  planning  and  management 
support,  be  cost  effectively  reused  or  adapted  for 
reuse.  Documentation  templates  and  software  templates 
'are  two  examples  which  offer  an  enormous  potential  for 
lowering  the  cost  of  SSP  software  and  improving  its 
reliability.  A  modest  investment  in  evolving  an 
appropriate  generic  classification  model  which  provides 
a  standard  interface  to  automated  browsing  and 
management  tools  is  sorely  needed. 

2.9  Significant  progress  towards  goals  of: 

.  lowering  life  cycle  costs 
.  lowering  life  cycle  risks 
.  improving  software  quality 
.  improving  human  productivity 

.  improving  the  adaptability  and  reliability  of  software 
can  be  achieved  via  the  SSE  in  time  to  support  the  goals  of 
the  SSP  only  if  we  eliminate  reinvention. 

Elaboration: 

There  are  two  classes  of  reinvention  that  must  be 
eliminated  to  the  maximum  extent  possible,  and  as 
quickly  and  consistently  as  possible.  They  are: 
mistakes  and  solutions.  The  selection  and  use  of 
appropriate  models,  standards  and  interfaces  as 
discussed  in  the  preceding  list  of  issues  and 
assumptions  are  believed  to  offer  a  major  step  toward 
the  elimination  of  both  types  of  re  invention 


2.10  An  Appropriate  software  engineering  education  and  training 
plan  for  NASA  and  its  constituency  is  essential  to  the 
success  of  developing  and  supporting  both  the  SSE  and  the 
SSP. 

Elaboration: 

The  preceding  list  of  issues  and  assumptions  are 
believed  to  be  indicative  of  substantive  trends  and 
developments  throughout  many  of  the  free  world's  leading 
institutions  of  government,  industry,  and  academia. 
However ,  to  leverage  and  to  contribute  to  these 
advancements  will  require  initiating  and  sustaining  an 
appropriate  education  and  training  plan.  Not  only  will 
this  benefit  the  SSP,  but  it  will  also  enhance  the 
portability  of  tools,  components,  object  bases,  and 
people  for  other  important  projects. 
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3.0  An  Outline  of  the  Principal  Requirements  for  a  MAPS5 

Table  1 

Requirements  to  Architectural  Features  Relationship 
_ Stoneman  Requirement  _ _ Architectural  Features 


General  Goals 

.  Portability  of  user  program 


.  Portability  of  toolset 


Database  Requirements 

.  Flexible  repository  for  all 
project  information 


.  Every  object  in  the  database  is 
accessed  by  its  distinct  name 

e  Database  shall  permit  relation¬ 
ships  between  objects  to  be  main¬ 
tained 

.  Database  shall  support  the  genera¬ 
tion  control  of  configuration 
objects 

,  Selection  within  a  version  group 

.  Database  shall  support  the  gen¬ 
eration  and  control  of  config- 
ation  objects 

.  Mechanisms  shall  be  provided 
whereby  objects  needed  to  re¬ 
create  a  specified  object  will 
continue  to  be  maintained 

.  All  objects  connected  with  a 
specific  project  area  can  be 
grouped  in  a  partition 

.  General  access  control 
associated  with  a  partition 

.  Support  for  program  libraries 


.  Use  of  Ada  and  Retargetable 
Rehos table  tools 

.  Coding  in  Ada,  layered 
architecture  of  environment 


u.  File  system  model  based  on  three 
node  types  with  attributes  and 
associates 

.  Ada-like  path  names  and  unique 
identifiers  attribute 

.  Associations 


,  Revisions 


.  By  revision  number 

.  Attributes  and  associations  man¬ 
ipulated  by  advanced  configura¬ 
tion  control  tools 

.  Derivations  history 


.  Hierarchical  nature  of  the  data¬ 
base 


.  Node  access  control 


.  Program  libraries  managed  as 
directories  in  a  database 
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Table  1  (con't) 


Stoneman  Requirement  Architectural  Features 


Database  Requirements  (con't) 

.  Access  control  to  any  object 
In  database 

•  database  shall  store  information 
which  allows  management  reports 
to  be  generated 

.  Reliable  storage  of  objects 
including  long-term  storage 

.  Database  must  support  differing 
"software  configuration,"  both 
consecutive  "released”  and 
separate  "models" 

.  History  on  configuration 
controlled  objects  must  be 
maintained 

Control  Requirements 

„  A  virtual  interface  which  is 
independent  of  any  host  machine 
shall  be  provided 

.  Achievability  of  command 

functions  from  Vithin  programs 


.  Command  language  is  to  be  Ada 


«  Must  support  development  of  Ada 
programs,  in  particular  separate 
compilation  features 

.  Tools  shall  be  written  in  Ada 
where  possible 

.  Inter-tool  communication  shall 
be  via  the  virtual  interface 

.  Uniform  error  handling 


.  Mode  access  control 


.  Predefined  attributes,  attribute 
access  tools  and  command  language 
processor 

.  Backup  and  archiving  tools 


.  Baselines  defined  by  advanced 
configuration  control  tools  and 
variation  node  in  basic  database 
structure 

.  Advanced  configuration  control 
tools  manipulating  attributes  and 
association  of  nodes 


„  Command  lanauase  and  KAPSE 

w  w 

interfaces 

.  Command  Procedures  written  in 
command  language  or  Ada  programs 
using  KAPSE  services 

.  Command  language  supported  by  a 
command  processor  which  interprets 
the  language 


.  Language  processing  tools  and 
program  libraries 


.  90%  of  toolset  in  Ada 


.  All  tools  interface  through 
command  languages  and/or  KAPSS 

.  Error  status  returns 


Stoneman  Requirement 
Toolset  Requirements  (con *  t) 


Table  1  (con’t) 


Architectural  Features 


.  Comprehensive  "help"  facility 
,  Extension  to  toolset  supported 


.  Testing  and  debugging  of  Ada 
programs  at  source  level 

.  Resident  testing  and  debugging 
facilities  to  host-resident 


.  The  Minimal  Toolset  shall  include 

-  text  editor 

-  prettyprinter 

-  language  translator 

-  linkers 

-  loaders 

-  set-use  analyzer 

-  control  flow  static  analyzer 

-  dynamic  analysis  tool 

-  file  administrator 

-  command  interpreter 

-  configuration  manager 


.  Help  and  help  tools 

.  Ada  program  access  to  KAPSE 
services  and  ability  to  execute 
Ada  Programs  directly  from 
command  language 

.  Debugger (s)  and  program  analysis 
tools 

.  Debugger  and  program  analysis 
tools  distribution  between 
host  and  target 

.  Toolset  provide  full  support. 
These  categories  of  tools  are 
provided  as  individual  tools, 
options  within  the  compiler  or 
as  a  collection  of  related  tools 
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I  A  Life  Cycle  Model  for  a  Software  Support  Environment 

The  attached  figure  adapts  the  symbolic  representation  of 
McDermid  and  RipKen  (1384)  to  the  model  described  in  T-'oQ  Standards 
2167  and  2168 ‘and  to  the  major  phases  and  activities  to  be 
supported  by  an  integrated  SSE. 

The  bottom  of  the  figure  depicts  a  foundation  for  the  SSE 
beginning  with  a  model  for  the  -Life  Cycle  Project  Object  Base" 
(LCPOB) .  Ideallv  this  model  would  be  strongly  typed  and  organised 
by  phase  attributes  with  traceability  and  accountability  threads 
that  can  be  clearly  audited  and  enforced  throughout  the  life 
cycle.  The  relevant  schemas  and  dictionaries  would  be  created  and 
maintained  via  the  EA/RA  moael  in  conformity  with  both  the  IRDS 
standard  for  schemas  and  dictionaries  and  the  CAIS  standard  for 
interfacing  and  access  control.  The  object  base  contains  on-line 
objects  and  references  to  off-line  objects  which  may  be  temporary 
or  under  baseline  control.  Included  are  libraries  of  technical 
tools,  management  tools,  and  reusable  components. 


The  integrity  and  value  of  the  LCPOB  are  maintained  with  the 
help  of  the  tools  and  procedures  of  a  hierarchy  of  three  software 
engineering  activities  that  permeate  the  life  cycles  LCPOB 
management,  configuration  management,  and  quality  management. 
Together  with  the  LCPOB,  these  three  layers  of  tools  and 
procedures  form  a  solid  foundation  for  an  extensible  SSE  that 
evolves  over  time  to  provide  highly  automated  support  for  all 
phases  of  the  project  life  cycle. 


Within  the  phases  (which  are  typically  going  to  be  subdivided 
into  collections  of  activities) ,  technical  and  management  tools 
can  be  developed  or  imported  which  support  the  four  components  of 
the  creating  and  recording  functions  common  to  each  phase;  i.e., 
the  creation  activities  (shown  as  rectangles)  ,  the  records  they 
produce  (shown  as  a  closed  pair  of  parallel  arcs)  the  verification 
and  validation  of  the  effects  of  the  creation  activities  based 


and  the  formal 
management  and 
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upon  the  records  they  produced  (shown  as  circles) 
review  process  that  allows  the  integration  of 

—  -  U.  -  J  -  m  j  w  ^  m  A  <rm  4m  •  *  W  A*  ^  ^  »•<»  S  1  <4  dW 

portion  of  the  figure  also  depicts  the  milestone  of  acceptance 
testing  which  transitions  software  components  from  a  development 
status  to  the  maintenance  and  operation  phase  (shown  as  an  oval)  . 


: 
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LEGEND  FOR;  “A  LIFE  CYCLE  MODEL  fOR  A  SOFTWARE  SUPPORT  S*mROKMENT,t 


Doeuaaentafcion 

©  Symbol:  A  closed  pair  of  parallel  arcs, 
o  Abbreviations; 

,  Sys  RAD:  System  Requirements  Analysis  Document 
.  Sv  RJVQ:  Software  Requirements  Analysis  Document 

.  Sv  &SD:  Software  Design  Specification  Document 

.  Sw  Des  D:  Software  Design  Documentation 
.  £w  Dev*  B:  Software  Development  Documentation 

Note:  Other  documentation  not  explicitly  shown  on  the  model  but 
which  is  required  by  DoD  Stds  2167  &  2166  and  which  should  be 
supported  by  the  environment  include; 

o  Life  Cycle  Content 

•  Computer  Resources  Lift  Cycle  Management  Plan 
©  Management 

„  Software  Development  Plan 

*  Software  Configuration  Management  Plan 
.  Software  Ouality  Evaluation  Plan 

c  Software  Standards  and  Procedures  Manual 

o  Design 

„  System/Segment  Specification 
.  System  Requirements  Specification 
.  Interface  Requirements  Specification 
.  Software  Top  Level  Design  Document 
.  Software  Detailed  Design  Document, 

.  Interface  Design  Document 
.  Database  Design  Document 
.  Software  Product  Specification 
.  version  Description  Document 

©  Teat 

.  Software  Test  Plan 
.  Software  Test  Description 
.  Software  Test  Procedure 
.  Software  Test  Report 

o  Operational  Support 

.  Computer  System  Operator's  Manual 
.  Software  User's  Manual 
.  Computer  Support  Diagnostic  Manual 
.  Software  Progcamer'a  Manual 
.  Firmware  Support  Manual 
.  Operational  Concept  Document 

.  Computer  Resources  Integration  Support  Document 
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Reuscable  Components; 

o  Includes  documentation,  requirements,  specification,  source 
code  components,  tools,  applications  libraries,  test  sets, 
budgets,  plans,  etc.  In  short,  any  work  component  with  a 
potential  to  be  developed,  imported  or  purchased  for  cost 
effective  reuse. 


Verification  %  Validation 

o  Symbol;  Circle  for  VfcV;  five  sided  figure  for  formal 
reviews 

o  Abbreviations; 

.  8RR;  System  Requirements  Review 
.  SDRs  System  Design  Review 
.  SSR:  Software  Specification  Review 
.  PQRs  Preliminary  Design  Review 
.  CDS;  Critical  Design  Review 
.  YRR:  Test  Readiness  Review 
.  FCA:  Functional  Configuration  Audit 
e  PCA;  Physical  Configuration  Audit 
.  FQR;  Formal  Qualification  Review 


Activity 

o  Symbol;  Three  are  shown  as  horizontal  layers 
persisting  throughout  the  life  cycle; 

1)  quality  management 

2)  configuration  management 

3)  project  object  base  management 

Also  note  the  symbols  for  the  formal  reviews  arid 
acceptance  testing. 

g  Definition;  "The  process  of  performing  a  series  of  actions 
or  tasks." 

(Joint  Regulation,  SDS  Documentation  Set,  4  June  1985) 

o  Note  by  CWM;  Some  activities  extend  across  all  phases  of 
the  life  cycle  (eg,  the  three  listed  above)  whereas  some 
phases  contain  a  collection  of  phase-specific  activities. 
(No  such  subdivisions  are  shown  on  this  figure.  However, 
these  phase-specific  activities  also  can  be  considered  in 
terms  of  the  four  symbols  common  to  the  phases-;  activity, 
documentation,  verification  &  validation,  and  review.) 
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Phage 


o  Symbol:  Rectangle 

o  Definition:  "A  discrete  period  of  time  delineated  by  a 
beginning  and  an  ending  event  for  each  iteration  in  the 
incremental  evolution  of  the  life  cycle."  (CWM,  1985) 

o  Abbreviations  for  2167  Phases: 

.  PI:  System  Requirements  Analysis 
.  P2:  Software  Requirements  Analysis 
.  P3:  Preliminary  Design 
.  P4 •  Detailed  Design 
.  P5:  Coding  &  Unit  Test 

.  PS:  Computer  Software  Component  Integration 


Transition  frow  Development  to  Maintenance  t  Operation 


n  C  a  i  wKaT  •  1 

«  •»  j  ««/  w*  •  VTU* 

o  Abbreviation: 

.  Acceptance  Testing  of  Computer  Software  Configuration 
Items 
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5.0  A  Prioritized  List  of  Needed  Tools  for  Initial  Operating 
Capability  (IOC)  in  June,  1987  and  for  the  Operating 
Capability  in  June,  1990 

Important  Notes;  all  tools  listed  below  are  intended  to 
extend  and  complement  the  HAPSE  as  described  in  Section  3.0  of 
this  report.  Furthermore,  regardless  of  the  development  language 
the  implementation  is  to  be  coded  in,  Ada  should  be  used  as 
an  executable  design  language  before  development  coding 
begins.  Both  configuration  management  and  verification  and 
validation  are  imposed  upon  the  executable  Ada  design  versions  as 
well  as  the  development  code  versions. 

Legend  : 

X  ■  Required 

O  »  Optional 

P1..P7  ■  Phases  1  through  7  of  the  Life  Cycle  Model 
all  ■  Supports  one  or  more  activities  throughout  all 
phases  of  the  life  cycle 
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TOOLS 


*87  *90  To  Support 


Problem  Expression  Editors 
Syntax  Directed/Teraplate  Driven 
Ada  Editor 

Semantics  Language  Processor 

Semantics  Analyzer 

Semantics  Information  Browser 

Dictionary  &  Schema 

Report  Generators 

Reusable  Components  Browser 

Reusable  Components  Design  Aid 

Modeling 

Simulation 

Resource  Estimator 

Automated  Precedence  Network 

Schedule  Generator/Analyzer 

Change  Request  Tracker 

Automated  Work  Breakdown  Structure 

Resource  Scheduling  Aid 

Standards  Checker 

Verifier/Asserticn  Analyzer 

Prototyping 

Graphics  Design  Aid 

Test  Data  Generator 
Test  Results  Comparator 
Test  Harness 
Scenario  Generator 
Environment  Simulator/Stimulator 
Per format ce  Monitor 
Black  Box  Test  Generator 
Data  Extraction  &  Reduction 
Test  Completeness/Consistency 
Analyzer 

Test  Coverage  Analyzer 
Interactive  Test  Analysis 
(with  a  fully  instrumented 
test  bed) 

Performance  Model 
Reliability  Model 
Event  Signaling  Path  Generators 
GKS  Graphics 

2  dimensional 

3  dimensional 

Design  Complexity  Analyzer 
Integrated  Text  a  Graphics  Forms 
Generator 
Menu  Manager 

Command  Language  Script  Manager  for 
Distributed  Processing 
Word/Document  Processing 

Integrated  with  Graphics  Support 
and  Electronic  Kail  and  Filing 
across  the  Distributed  System 


0 

R 

P1..P3 

R 

R 

P3..P7 

O 

R 

P1..P3 

0 

R 

P1..P3 

0 

R 

PI. .P3 

R 

R 

all 

R 

R 

all 

R 

R 

all 

0 

R 

P4..P7 

R 

R 

P1..P4 

0 

R 

PI. .P2 

0 

R 

all 

0 

R 

all 

0 

R 

all 

R 

R 

all 

0 

R 

all 

0 

R 

all 

0 

R 

P4..P7 

0 

0 

P1..P3 

0 

R 

P4. .P7 

0 

R 

P1,P2,P4 

0 

R 

P4 

0 
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R 

R 

P4..P7 

R 

R 

P4..P7 

R 

R 

P4..P7 

0 

R 

P4..P7 

0 

R 

P4..P7 

0 

R 

P4..P7 

0 

R 

P4..P7 

0 

R 

P4..P7 

0 

R 

P4..P7 

0 

R 

P4..P7 

R 

R 

F4. .P7 

0 

R 

P4..P7 

0 

R 

all 

0 

R 

all 

R 

R 

P4..P7 

0 

R 

P4..P7 

R 

R 

P4..P7 
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R 
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R 

R 

all 

R 

R 

all 

0 

R 
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TOOLS 


*87  *90  To  Support 


Communications  Tools  to  link  the 

Hosts  and  Targets  R 

Real  Time  Programming  Aid  0 

Expert  System  Generator  R 

Cross  Reference  Analyzer  R 

Statement  Profile  Generator  R 

Compilation  Order  Analyzer  R 

Intelligent,  Automated  Recompilation  R 
Generic  Instantiation  Analyzer  R 

Generic  Instantiation  Reporter  R 

DIANA  Tree  Browser  R 

DIANA  Tree  Expander  R 

Impact  Analyzer  for  Module  Changes  R 

Call  Tree  Analyzer  R 

Elaboration  Dependency  Analyzer  R 

Execution  Metrics  Analyzer  R 

Run  Time  Support  Dependencies 

Analyzer  O 

Distributed  Workload  Simulator  R 

Fault  Tolerance/Safety  Analyzer 

and  Simulator  O 

Fault  Tolerance  Programmers  Aid  O 

Run  Tima  Support  Environment  Monitor  R 

m  4  «  _  p  . m  4  _  4  ....  —  —  /-» 

ixuii  z  amc  w  a  Ar.i. 

Run  Time  Support  Storage  Analyzer  O 

Run  Time  Support  Tasking  Analyzer  O 

Target  Network  Topology  Specifier  R 

Target  Node  Resources  Specifier  R 

Distributed  Target  Node  Restriction 
Checker  O 

Partitioning  and  Allocation  Tool  R 

Distributed  Program  Builder  R 

Distributed  Program  Resource 

Sharing/Replication  Analyzer  0 

Upgrade  Load,  Test  and  Integration 

Planning  Aid  for  Non-stop  Nodes  0 


R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 
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6.0  A  Brief  Description  of  fc&e  Tools  in  the  Context  of  the  Model 

REQG I&fiMENTS  ANALYSIS 
CHARACTERISTICS,  PRINCIPLES  AND  METHODS 


Several  approaches  can  be  used  during  requirements  interpretation, 
feasibility  studies,  and  analysis. 

Semantics  Information  Capture  -  Supporting  Interpretation,  the 
capture  of  requirements  in  the  form  of  a  semantic  model  involves 
identifying  key  terms,  categorising  the  terms,  defining  the  terms,  and 
identifying  the  relations  between  the  terms.  The  capture  of  semantics 
information  creates  a  lormal  recording  of  the  semantic  model  of  the 
requirements,  which  become/,  part  of  the  baseline.  Assuming  the 
semantics  information  is  raachinv-encoded,  it  might  be  expressed  in  a 
formal  language  such  as  Problem  Statement  Language  (PSL)  or  in 
combination  of  formal  graphics  and  text  expression  such  as  Software 
Requirements  Engineering  Methodology  (SAEM) . 

Semantics  Analysis  -  Ouce  tae  requirements  are  expressed  in  the 
context  or  a  semantic  mode',,  ths  model  relations  can  be  used  fv"'  a 
systematic  analysis  of  the.  completeness  and  consistency  of  the 
requirements.  This  is  achieved  by  asking  questions  which  are  answered 
with  the  aid  of  the  relations.*  a«  *Ar®  there  any  other  processes 

which  should  be  related  to  Process  A  by  the  'predecessor  of*  relation?" 

Traceability  may  be  established  through  reference  relations  between 
requirements  and  specification,  design  and  code,  etc.  The  relational 
analysis  can  be  used  ta  atmess  the  impact  of  requirements  changes  on 
the  baselined  products. 

The  semantic  analysis  method  also  aids  creation  by  identifying  areas  of 
requirements  incompleteness  or  inconsistency. 

Feasibility  and  Risk  Analysis  -  Evaluating  the  feasibility  of  requirement 
is  a  significant  £>«rt  of  requirements  analysis.  Feasibility  should  be 
viewed  from  the  perspectives  of  design,  performance  and  cost. 

Design  feasibility  involves  finding  at  least  one  design  that  satisfies 
the  requirements.  Any  approach  from  trial  design  to  prototyping  is 
appropriate.  Performance  feasibility  is  a  special  case  of  design 
feasibility  analysis.  Once  a  trial  design  is  established,  modeling  is 
an  effective  technique  for  analyzing  performance.  Cost  feasibility 
involves  estimating  costs  based  on  the  trial  design.  Cost  analysis 
must  consider  ti.a  three  key  elements:  the  development  phase,  the 
operations  phase,  and  the  phase  for  continuing  adaptation. 


SUPPORTING  TOOLS 


Several  tools  are  effective  in  supporting  the  above. 

Problem  Expression  Editors  -  These  editors  permit  capturing  a  form 
expression  of  the  problem  in  text  and/or  graphics  form.  The  form, 
expression  obeys  language-like  rules  and  can  then  be  machine  processed  v 
a  Semantics  Language  Processor. 

Semantics  Language  Processor  -  A  language  processor  performs  syntax 
checking  and  recording  of  semantics  information  entered  via  a  form 
expression  such  as  PSL.  The  results  are  available  for  later  analysis  or 
retrieval.  The  Information  resembles  a  data  dictionary  augmented  by 
relations. 


Semantics  Information  Browser  -  This  tools  stores  and  retrieves 
the  semantic  information.  It  might  be  based  on  a  data  base  management 
system  (DBMS)  using  relational  techniques.  An  example  of  such  a  tool 
used  in  this  application  is  IBM's  Query-by-Example  (QBE). 

Semantics  Information  Analyser  -  This  tool  uses  the  relational  nature 
of  the  semantics  information  To  perform  consistency  and  completeness 
checks.  Problem  Statement  Analyzer  (PSA)  is  an  example  of  a  tool  used 
to  analyze  data  captured  through  the  use  of  PSL. 


Report  Generator  -  General  report  generators  would  help  create 


w  i  i  r«  e 


analysis  reports.  Examples  of  reports  are: 


-  Pormatted  problem  statement  report,  which  gives  the  original 
relationships  in  a  well-structured  format, 

-  Structure  report,  which  presents  relationships  as  a  hierarchy, 

-  Data  structure  report,  which  lists  data  structures  and  the 
types  of  their  contents, 

-  Data/ activity  interaction,  which  shows  interaction  between 
data  objects  and  activities,  and 

-  Picture  report,  which  diagrams  the  direct  relationships  of 
an  object. 

-  2167/2168  reports 


Modeling  Tool  -  This  tool  provides  queuing  theory  aids  tailored  to 
descriptions  of  computer  systems.  The  tool  assists  in  developing 
performance  analysis  models.  Performance  Oriented  Design  is  an  example 
of  such  a  queuing  tool.  Other  modeling  tools  besides  queuing  would 
also  be  appropriate. 

Resource  Estimator  -  An  estimation  model  helps  assess  cost 
feasibility.  The  model  uses  characteristics  of  the  software  systen  and 
the  development  approach  to  predict  required  manpower,  schedule,  and 
computer  resources. 
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Proto '.yping/S imulation  -  These  are  software  tools  for  developing  simulatic 
or  computer  based  prototypes  of  software  systems.  They  could  consist  of  z 
high-level  language  and  an  interpreter,  with  statistical  analyses  packages 
The  CJ.S.  Air  Force  tool,  SAINT,  is  an  example. 


REQUIREMENTS  ON  THS  SSS 

The  requirements  on  the  SSE  data  base,  derived  from  requirements 
analysis,  arei 

Baselined  Products  for  Past  and  Present  Phases  of  Evolution  -  The  semantic 
information  is  the  only  data  associated  with  requirements  analysis  th« 
should  be  baselined.  It  should  be  under  configuration  control  and  subjet 
to  change  only  as  requirements  changes  are  approved.  Baselined  data  shoul 
not  only  include  the  flshallsa  of  each  phase  (which  must  be  dichotomous) 
demonstrated  at  acceptance  test  time)  but  also  the  "shoulds"  which  ha\ 
life  cycle  implications  that  cannot  be  dichotomously  demonstrated  i 
acceptance  test  time  and  which  may  require  the  design  of  special  metric 
and  instrumentation  to  support  their  analysis  at  subsequent  points  in  tt 
life  cycle. 

Non-Basellned  Data  -  Any  information  associated  with  modeling, 
simulation,  prototyping,  or  semantic  analysis  should  be  saved 
temporarily.  It  should  be  used  later  in  requirements  analysis 
iteration  or  other  activities. 

Measurement  Data  -  Several  measurements  of  the  requirements  analysis 
activity  and  its  outputs  should  be  captured: 

-  Size  of  the  data  base  for  semantics  information, 

-  Complexity  of  the  requirements  as  measured  by' the  relationships 
in  the  semantics  information  and 

-  Number  of  inconsistencies  or  omissions  found. 


PKKL^mnARX  ufisum/  uboaw  SPECIFICATION 
CHARACTERISTIC,  PRINCIPLES  AND  METHODS 

Formal  Recording 

The  specification  information  must  be  recorded  in  some  suitable  form. 

As  a  minimum,  the  specification  should  describe: 

Translation  -  o the  "shalls”  from  requirements  analysis  into  Ada  packa 
specifications.  Functional  requirements  should  be  transformed  in 
functional  Ada  specifications  that  can  be  checked  by  an  Ada  Compile 
Non-functional  requirements  (i.e.,  constraints)  should  be  transformed  in 
a  discipline  of  Ada  comments  that  can  be  checked  by  other  APSE  tools. 

Interactions  -  the  interactions  of  the  software  system  and  its 
outside  environment  (i.e.,  descriptions  of  the  I/O  device  interfaces, 
sensor  interfaces,  etc.); 


3-444 


DETAILED  DESIGN 


CHARACTERISTICS ,  PRINCIPLES  AND  METHODS 


Three  groups  of  design  support  ere  identified:  formal  recording  of 
system  design,  formal  recording  of  data  and  program  design,  and 
creative  aids. 

There  are  several  techniques  for  recording  the  system  design. 

Information-Hiding  -  This  technique  involves  isolating  information 
within  modules.  The  module  limits  are  defined  by  the  information 
(design  decisions,  data  definitions,  etc.)  to  be  isolated.  Design  is 
based  on  the  expected  changes  to  the  information,  thus  localizing  the 
effect  of  future  changes. 

Module  Specification  -  This  technique  allows  others  to  determine  the 
intent  of  a  complete  module  by  reading  the  module  specification. 

Psea  Hierarchy  -  This  technique  explains  which  programs  depend  on  the 
correct  implementation  of  a  given  module  to  produce  correct  results. 

The  techniques  for  the  formal  recording  of  data  design  and  program 
design  are: 

Program  Design  Language  (PPL)  -  PDL  is  a  useful  technique  for 
formally  recording  the  program  design.  It  is  sufficiently  low-level  to 
support  direct  coding,  and  is  flexible  enough  to  leave  some  questions 
unanswered  while  the  designer  proceeds  with  the  design.  (i.e.,  Ada  sour 
code  with  Ada  "stubs".) 

Stepwise  Refinement  ~  This  technique  goes  hand  in  hand  with  POL. 

With  stepwise  refinement,  specifications  for  the  lower  level  code 
become  part  of  the  documentation  of  the  procedure.  This  makes  the 
intent  of  the  code  much  clearer. 

Abstraction  of  Dab?  Types  -  wirh  abstraction,  the  designer  can 
develop  details  where  they  are  needed.  This  permits  information-hiding 
as  well  as  a  more  independent  implementation  of  the  system. 

Many  creative  techniques  exist  for  design.  A  designer  chooses 
techniques  based  on  their  individual  approach  to  creativity.  Some 
prefer  graphic  techniques  while  others  do  not.  The  choice  of  creative 
techniques  should  be  left  to  the  individual,  whereas  the  techniques  for 
formal  recording  must  be  standard.  Described  below  are  some 
representative  creative  aids: 

Data  and  Control  Plow  Analysis  -  Module  decomposition  and  functi 
allocation  are  based  upon  the  data  and  control  flows  required  by  t 
system.  An  example  is 
Structured  Design. 

Data  Structure  Transformation  -  Transformation  is  a  design  technique 
in  which  the  structure  of  the  input  and  output  data  determines  the 
structure  of  the  program. 


Graphic  Decomposition  Techniques  -  Graphs  showing  hierarchic 
relations  depict  the  decomposition  at  many  levels.  An  example  is 
Structured  Analysis  and  Design  Technique  (SADT) . 

Graphic  Control  Descriptions  -  Other  ways  of  showing  the  control 
flows  in  the  program  are  Petri  Nets  and  Warnier-Orr  diagrams. 

SUPPORT  TOOLS 

Design/Specif ication  Language  Processor  -  These  check  syntax  and 
connections.  Input  is  the  system  design  and  the  module  specifications 
written  in  some  standard  syntax.  Output  is  a  list  of  inconsistencies 
or  syntax  errors.  (eg,  an  Ada  compiler  for  functional  requirements  at 
other  MAPSE  tools  for  non-functional  requirements.) 

PPL  Syntax  Analyzer  -  These  detect  mismatched  interface  items  and 
force  the  designers  to  maintain  a  consistent  syntax  for  the  .design. 

Input  is  a  design  written  in  a  PDL,  and  output  is  a  list  of  syntax 
errors  and  inconsistencies  in  data  usage.  An  Ada  compiler  supports  this. 

PDL  Interpreter  -  These  allow  a  design  to  be  executed  before  it  is 
actually  coded.  The  interpreter's  input  is  a  design  written  in  a  PDL 
with  program  input  data.  Its  output  shows  the  result  of  applying  the 
input  data  to  the  design.  An  Ada  compiler  supports  this. 

Graphics  Package  -  These  support  the  creative  phase  of  design. 

Various  designs  could  be  displayed  graphically  to  aid  the  designer  in 
making  a  choice.  Input  might  be  module  descriptions,  hierarchy 
relations,  or  data-use  relations.  Outputs  include  graphic 
representations  of  this  information. 

Modeling  Tools  -  These  are  used  for  judging  how  feasible  particular 
designs  are.  A  model  might  take  a  high-level  design  as  input.  It  then 
produces  execution  and  timing  statistics.  These  statistics  are  used  to 
determine  if  the  design  could  meet  the  performance  requirements. 

Report  Generators  -  These  transform  stored  design  into  documents  and 
reports.  Thus  the  baselined  design  will  be  stored  in  machine-readable 
form,  permitting  required  documents  to  be  produced  easily. 


REQUIREMENTS  ON  THE  SSE 

As  with  the  other  activities  of  development,  the  data  base  must  contain 
information  on  the  design. 

Baselined  Products  -  Throughout  the  life  of  the  system,  the  most 
recently  approved  form  of  the  design  must  be  stored  in  the  data  base. 
The  system  design  are  entered  before  the  design  of  various  subsystems 
or  modules. 

Non-Baselined  Data  -  This  includes  preliminary  designs  as  well  as 
graphic  displays  used  during  the  creative  process.  Graphic  displays 
include  tree  structures,  block  diagrams,  and  other  material  created  by 
design  tools.  The  data  base  must  provide  for  maintaining  the  temporary 
designs  developed  before  one  is  actually  chosen  and  baselined. 

Measurements  -  These  should  include  module  interconnection 
measurements,  such  as  data  bindings.  These  should  also  include  lower 
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design  measurements,  such  as  cyclomatic  complexity,  and  operators  and 
operands.  Many  of  these  measurements  are  normally  taken  on  the 
completed  code,  but  with  good,  low-level  PDL,  they  can  be  taken  (or 
approximated)  during  design. 

Archival  Data  -  Archived  data  should  capture  the  motivation  behind 
the  choice  of  design.  The  archived  data  should  also  include  past 
designs  evolved  from  use  or  rejected  during  development  along  with  the 
reasons  for  the  rejection. 


VERIFICATION  AND  VALIDATION 
CHARACTERISTICS,  PRINCIPLES  AND  METHODS 


The  methods  linked  with  correctness  analysis  are  either  static 
analysis  or  dynamic  analysis.  Static  analysis  includes,  in  order  of 
increasing  rigor,  reviews,  inspections,  and  proofs  of  correctness. 
Dynamic  analysis  includes  all  testing  techniques. 

Reviews  -  Reviews  determine  the  internal  completeness  and  consistency 
of  system  requirements  and  software  specification,  design  and  test 
information.  They  also  assess  its  consistency  with  its  predecessor 
information.  Reviews  involve  a  broad  range  of  people,  including 
developers,  managers,  users,  and  outside  experts  or  specialists.  A 
review  must  have  specific  objectives  and  questions  to  be  addressed. 

The  review  findings  generate  rework  tasks  for  the  development  group. 

Inspections  -  Inspections  evaluate  the  correctness  of  component  level 
specification,  design,  code,  test  plans,  and  test  results.  They  are 
more  formal  and  rigorous  than  reviews.  An  inspection  involves  a  small 
group  of  people  of  a  specific  make-up,  and  follows  a  well-defined 
procedure. 

Proofs  of  Correctness  -  All  development  products  should  be  verified 
with  an  informal  proof  of  correctness.  Certain  critical  kernals  of 
code  or  special  applications  may  require  a  formal  proof  of  correctness.. 

Testing  -  Dynamic  execution  of  the  system  or  system  component  with 
known  inputs  in  a  known  environment  is  a  “test*.  If  the  test  result  is 
consistent  with  the  expected  result,  the  component  is  deemed  correct  in 
the  limited  context  of  the  test.  The  following  baselined  documents  are 
created  relative  to  testing: 

-  Test  Plan  -  Defines  the  scope,  approach,  and  resource  needed 
for  testing. 

-  Test  Procedures  -  Provides  a  detailed  description  of  the 
steps  and  test  data  associated  with  each  test  case, 

-  Test  Results  -  Documents  the  results  of  each  test  run. 
Unsuccessful  runs  trigger  trouble  reports  which  must  be 
addressed  by  the  development  group. 

There  are  two  approaches  to  testing — black-box  testing  and  white-box 
testing.  Black-box  testing  uses  only  knowledge  of  externals  (to  the 
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function)  while  white-box  testing  uses  knowledge  of  the  internal  design 
of  the  function, 

Black-box  testing  uses  the  specification  to  develop  test  cases  and  is  mo 
appropriate  for  system  testing  because  it  directly  demonstrates 
that  the  implemented  system  satisfies  the  specification.  White-box 
testing  uses  design  information  to  develop  test  cases  and  is  most 
appropriate  for  component  testing. 

The  relationships  between  system  functions  and  component  or  system  test 
cases  should  be  clearly  established.  Then,  when  changes  are  made  to 
parts  of  a  ay stem,  a  subset  of  test  cases  can  be  identified  which  will 
test  the  system  sufficiently.  This  process  is  called  regression 
testing.  Effective  regression  testing  is  a  good  way  to  reduce  software 
development  costs. 


SUPPORT IMG  TOOLS 

A  representative  set  of  tools  to  support  validation  is  listed  below. 

Performance  Model  -  Performance  models  evaluate  system  performance 
constraints  such  as  response  time.  The  evaluation  is  performed  by  an 
analytic  model  or  simulation  model  based  on  the  system  design.  If  the 
performance  model  is  used  to  evaluate  requirements  feasibility,  a 
high-level  design  is  assumed.  Performance  models  have  been  developed 
for  many  systems.  Currently  developed  is  a  generalized  modeling  tool 
called  Performance  oriented  Design. 

Prototyping  Aid  -  Developing  an  operational  prototype  allows 
evaluation  of  requirements  and  design  approaches.  Executable  design 
language  are  useful  in  this  regard. 

Congjatcncy/Completenesa  Analyzer  -  These  tools  aid  analysis  of 
internal  consistency  and  completeness  when  specification  requirements 
are  expressed  in  a  machine- interpretable  form. 

Standards  Checker  -  Standards  checkers  perform  static  analysis  of 
code  or  documentation  and  identify  standards  violations. 

Verif icr/Aaaertion  Analyzer  -  These  analyzers  verify  that  code  correctly 
implemented  specifications  by  checking  the  truth  of  the  assertions 
(embedded  in  the  code)  against  actual  program  execution. 

Symbolic  Execution  -  Symbolic  execution  is  used  for  proving  the 
correctness  of  certain  classes  of  programs.  It  involves  "executing" 
them  symbolically  to  prove  certain  assertions. 

Theorem  P rover  -  Theorem  provers  automate  proof-of-correctness 
techniques. 

Teat  Harness  -  A  test  harness  provides  the  framework  for  unit  testing 
of  procedures.  With  it,  programmers  can  interactively  define  the 
procedure  interface,  prepare  test  data,  run  an  instrumented  test,  and 
display  the  test  result. 
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Test  Data  Generator  -  Based  on  a  given  testing  strategy  such  as  "test 
every  path",  this  tool  will  automatically  develop  test  cases  based  on  t 
code  or  perhaps  the  design. 

Hardware  Simulator  -  Hardware  simulators  allow  object  code  for  a 
target  computer  to  be  tested  on  the  host  computer. 

Host-Target  Compiler  -  A  software  alternative  to  hardware  simulators 
which  use  source  text  to  generate  object  code  that  executes  on  the  host 
computer. 

Test  Results  Comparator  -  This  tool  compares  actual  unit  test  results 
against  expected  results.  It  issues  a  trouble  report  if  the  test 
results  are  not  correct. 

Environment  Simulator/Stlmulator  -  The  simulator  duplicates  the 
operational  environment  of  the  ECS  in  a  test  facility.  This  is  done 
before  integration  with  the  sensor  and  effector  systems.  The  stimulator 
tests  the  system  by  simulating  input  such  as  sensor  and  effector 
interface  signals. 

Performance  Monitor  •  These  tools  permit  measurement  of  system 
performance  parameters,  such  as  response  time,  algorithm  processing 
time,  channel  utilization,  etc. 

D  ,ta  Extraction  and  Reduction  -  These  tools  analyze  the  system 
dynamically.  During  execution,  data  is  captured  and  stored,  and  later 
reduced  by  processing  to  create  reports  for  the  dynamic  analysis 
activity. 

Scenario  Generator  -  These  tools  control  the  complex  parameters  which 
create  the  scenarios  and  drive  the  simulation  of  the  environment 

Black-Box  Test  Generator  -  These  tools  generate  functional  test 
skeletons  by  using  the  specification  of  the  software  system.  The 
analyst  then  completes  the  scenarios  by  adding  detail  to  the  skeleton. 

The  tools  should  include  sampling  techniques  to  assure  adequate 

rnv»rxa*  nf  t-hsm  i  f  on. 

- ? '  -  ^ — — - -  ^  — 

Test  Coverage  Analyzer  -  These  tools  analyze  the  testing  status  of 
Software  Component  Item  as  software  progresses  from  unit  testing 
integration. 

Interactive,  Fully  Instrumented  Test  Bed  -  These  tools  support  interact! 
testing'  between  the  host  and  a  target  test  bed  that  is  fully  instrument® 
The  environment  stimulator/simulator  may  be  used  to  provide  a  context  £ 
the  subsystem  component  under  test. 

Reliability  Model  -  These  tools  use  the  error  history  of  the  system 
over  its  life  cycle  to  estimate  a  reliability  measure  for  the  system. 

REQOIREKHNTS  OH  THE  SSB 

The  requirements  on  the  SSE  data  base,  derived  from  the  correctness 
analysis,  are  summarized  below: 
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Baselined  Products  -  Test  plans,  test  procedures  and  test  results  (of 
correctly  executed  tests)  ace  all  baselined.  They  are  controlled  by 
configuration  management.  The  results  of  inspections  and  proofs  might 
also  be  baselined. 

Non-Baaelined  Data  -  The  non-baselined  data  includes 

work- in-progress,  static  analysis  data,  trouble  reports,  and  debug 

data.  Temporary  storage  of  this  type  of  information  is  required. 

Measurement  Data  -  A  number  of  measurements  associated  with 
correctness  analysis  should  be  captured.  These  include:  number  of 
modifications  to  a  unit,  number  of  errors  found  per  unit,  number  of 
test  runs,  number  of  errors  by  error  category,  and  test  coverage. 


PROJECT  MANAGEMENT  SUPPORT 
CHARACTERISTICS,  PRINCIPLES  AND  METHODS 


Estimation  -  Most  resource  estimation  techniques  use  the  measurements 
From  prior  projects  to  estimate  resources.  Support  of  estimation 
methods  requires  a  data  base  of  comprehensive  measurements  including 
such  software  system  parameters  as  size  of  source  code,  source 
language,  development  resources  expended,  and  complexity  measures. 

Precedence  Networks  -  This  planning  method  is  used  to  analyze  task 
dependencies  and  to  determine  the  critical  path  of  development 
activities.  Such  an  analysis  is  usually  needed  to  define  a  realistic 
schedule.  It  is  also  useful  in  evaluating  contingencies  and  creating 
contingency  plana. 

Change  Control  -  This  is  the  core  of  configuration  management.  It 
controls  all  changes  to  baselined  products.  The  approval  process  for 
changes  might  be  as  follows: 

-  The  written  request  for  change  is  submitted  to  the 
configuration  management  function.  It  might  come  from  a  change 
in  requirements  or  from  a  trouble  report  documenting  a  defect. 

~  An  assessment  is  made  of  the  technical  feasibility  of  the 

change,  and  its  impact  on  schedule  and  budget.  If  it  has  t: 
potential  to  endanger  life  and  property,  a  separate  safe 
assessment  may  be  made. 

-  The  change  in  approved  or  disapproved  based  on  its  potenti 
effect  upon  safety,  its  value  and  its  cost. 

-  The  development  plan  is  modified  and  resources  adjusted 
to  add  approved  changes. 

-  The  fully  verified  change  is  entered  into  the  new  baseline. 
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SUPPORTING  TOOLS 


Many  tools  are  applicable  to  management  and  can  support  the  methods  and 
activities  described  above,  3orae  of  the  more  useful  tools  for 
management  include: 

Resource  Estimation  Model  -  This  software  uses  a  data  base  of 
measurements  on  past  projects,  along  with  a  description  of  the  new 
system,  to  create  resource  estimates  for  development. 

Automated  Precedence  network  -  This  software  creates  precedence 
network  charts  and  determines  the  critical  path  based  on  the  input  of 
detailed  milestones  and  precedence  relations. 

Automated  WB5  -  This  tool  helps  to  create  budgets  and  a  work 
breakdown  structure. 

Schedule  Generator  -  This  tools  uses  output  from  the  precedence 
network,  and  organizational  responsibilities  (related  to  the  WBS) ,  to 
create  schedules  by  organizational  entity. 

Change  Request  Tracker  -  Tnis  tool  logs  change  requests  when 
submitted,  tracks  them  through  the  approval  cycle,  and  records  their 
resolution. 

Resource  Scheduling  Aids  -  These  tools  permit  resources,  such  as 
computers,  conference  rooms,  terminals,  and  test  equipment,  to  be 
scheduled.  Usage  reports  on  the  resources  and  the  scheduling  of  the 
resources  are  the  vain  functions  of  these  tools. 

Event  Signaling  Path  Generators  -  These  tools  allow  events  such  as  fork  a 
]om  points  In  the  precedence  network  or  the  schedule  generator  or  even 
in  the  resource  usage  reports  to  be  linked  with  communicatio 
messages/notices  to  be  automatically  forwarded  to  designated  individua 
when  the  event  occurs. 

Report  Generators  -  Report  generators  create  management  reports  on 
technical,  budget,  and  administrative  status. 

REQUIREMENTS  ON  THE  SSX 

The  activity  of  management  imposes  the  following  requirements  on  the 
SSE  data  base. 

Baselined  Products  -  The  development  plan,  although  not  a  part  of  the 
software  system  or  its  descriptive  information,  should  be  maintained  as 
a  baselined  product  to  insure  proper  management  of  changes  to  the  plan. 
Configuration  management  data  and  quality  assurance  plans  should  also 
be  baselined. 

Non-Baselincd  Data  -  Significant  amounts  of  information  associated 
with  the  management  must  be  kept  temporarily.  This  information 
includes  engineering  change  requests,  trouble  reports,  resource 
allocation  plans,  actual  resource  utilization  reports,  technical 
milestone  status,  action  item  status,  and  the  results  of  quality 
assurance  reviews. 


Measurement  Data  -  Many  measurements  are  of  interest  to  management. 
These  include  the  number  of  engineering  change  proposals  (ECP) ,  and 
trouble  reports  (TR) ,  time  to  process  an  ECP  or  TR,  resource  use  for 
each  ECP  or  TR,  resource  use  by  project  activity,  and  software  size  and 
complexity  measures. 
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UTILITIES  WHICH  SUPPORT  ONE  OR  MORE  ACTIVITIES  THROUGHOUT  ALL 

PHASES  OF  THE  LIFECYCLE 


CHARACTERISTICS,  PRINCIPLES  AND  METHODS 


There  are  many  utilities  which  are  useful  to  both  management 
personnel  and  technical  personnel  throughout  the  lifecycle.  Even 
in  those  cases  where  om  group  is  responsible  for  creating  as  well 
as  reading  the  information,  and  the  other  group  is  primarily  a 
consumer  of  the  information,  these  utilities  are  useful  for  both 
groups  to  understand.  They  include  such  things  as  dictionary  and 
schema  definers,  report  generators,  reuseabie  components  browser, 
schedule  generators,  electronic  mail  and  filing,  and  ad  hoc  report 
,  generation. 


SUPPORTING  TOOLS 


Dictionary  and  Schema  Tools.  All  large,  complex  systems  can  be 
divided  into  "subsystems .  The  structure  of  the  subsystems  is 
usually  defined  by  the  technical  personnel  as  a  schema.  The 
definitions  of  the  subsystems  elements  are  typically  stored  in-  a 
dictionary.  The  IRDS  draft  standard  proposes  a  standard  way  of 
defining  and  maintaining  the  schema  and  dictionary  with  the  EA/RA 
model. 

Report  Generators.  Both  scheduled  and  ad  hoc  reports  are  prepared 
by  both  technical  and  management  personnel.  Wherever  possible, 
report  templates  should  be  generated  and  stored  as  reuseabla 
components.  DOD  standard  2167  contains  several  examples  of  such 
templates. 

Reuseabie  Components  Browser.  Although  many  components  are 
potentially  cost  effective  to  reuse  throughout  the  lifecycle, 
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components  which  may  include  plans,  budget  formats,  etc. 
Technical  personnel  can  make  effective  use  of  both  reuseabie 
software  and  reuseabie  documentation  components.  A  browser  which 
provides  semantic  information  overlayed  upon  a  common 
classification  scheme  with  key  words  can  facilitate  this  reuse. 

Resource  Estimator.  Several  microscopic  tools  for  estimating 
resources  required  for  a  small  activity,  to  macroscopic  tools  for 
estimating  resources  required  tor  a  subsystem  are  needed  by  both 
technical  and  management  personnel. 

Automated  Precedence  Network.  This  is  a  similar  tool  to  one 
described  under  project  management  support. 

Schedule  Generator/Analyzer.  This  is  similar  to  the  one  describsd 
under  project  management  support. 
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Change  Request  Tracker.  This  is  similar  to  the  one  described 
under  project  management  support. 

Automated  Work  Breakdown  Structure.  This  is  similar  to  the  one 
described  under- project  management  support . 

Resource  Scheduling  Aide.  This  is  similar  to  the  one  described 
under  project  management  support. 

Reliability  Model.  This  is  similar  to  the  one  described  under 
verification  and  validation. 

Event  Signaling  Path  Generators.  This  is  similar  to  one  described 
under  project  management  support* 

Integrated  Text  and  Graphics  Forms  Generator.  This  is  useful  to 
both  management  and  technical  personnel  for  generating  new  forms 
appropriate  for  use  on  a  specific  portion  of  the  project. 

Menu  Manager.  This  allows  both  technical  and  management  personnel 
to  create  their  own  menus  for  personal  or  team  utilization. 

Command  Language  Script  Manager  for  Distributed  Processing.  Many 
projects  require  both  technical  personnel  and  management  personnel 
to  access  computing  resources  across  a  collection  of  distributed 
hosts.  For  example#  a  report  is  to  be  generated  requiring  access 
to  objects  at  three  remote  sites  with  the  results  to  be  printed  at 
a  fourth  site.  This  tool  allows  those  scripts  that  are  to  be  used 
frequently  to  be  prepared#  stored  and  scheduled  for  appropriate 
distributed  processing. 

Communications  Tools  to  Link  Hosts  and  Targets.  Both  management 
and  technical  personnel  are  likely  to  need  host-to-host 
communications.  Technical  personnel  are  also  likely  to  need 
host-to-taraet  communications  for  such  purposes  as  interactive 
debugging#  status  queries#  upgrades#  etc. 

Word/Document  Processing  Integrated  With  Graphic  Support  and 
Electronic  Mali  and  Filing  Across  the  Distributed  System. 
Electronic  mail  and  filing  are  useful  to  both  technical  and 
management  personnel  across  the  distributed  system.  This  support 
can  be  particularly  useful  if  it  can  be  integrated  with  graphic 
support  and  an  interface  to  the  project  object  base  and  other 
utilities. 


REQUIREMENTS  ON  THE  SSE 

Baselined  products  -  The  products  accessed  and  manipulated  by 
these  tools  which  are  under  baseline  control  include: 
dictionary's,  schemas,  and  certain  schedules  which  are  formally 
approved  parts  of  the  development  plan. 
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Non-Basel ined  Data.  Much  of  the  information  associcated  with  the 
tools  of  this  section  must  be  kept  temporarily.  This  may  include 
memos*  ad  hoc  reports*  certain  forms*  and  scripts  of  the  dialog 
between  host  and  the  working  subsystem  of  a  target  environment. 

Measurement  Data.  Many  measurements  are  of  interest  to  managment. 
Of  particular  interest  are  schedule  changes  and  changes  to  the 
dictionaries  and  schema. 
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CODING,  UNIT  Tt’STING  AND  INTEGRATION  TESTING /DEVELOPMENT 
CHARACTERISTICS,  PRINCIPLES  AND  METHODS 


Designs  which  map  program  entities  across  distributed  processing 
resources  should  be  specified  in  two  complementary  parts.  First, 
the  functional  requirements  should  be  demonstrated  to  be  met  by 
the  program  design  by  executing  the  program  in  the  host 
environment.  (le,  compile  and  execute  the  Ada  source  code  on  the 
host  system  without  regard  to  properties  of  distribution.) 
Second,  the  non-functional  requirements  (ie,  constraints)  such  as 
the  location  each  program  entity  is  to  be  assigned,  timing 
constraints,  sizing  constraints,  etc.  should  be  mapped  to  a 
simulator  for  analysis  of  the  implications  of  imposing  these 
restrictions  upon  the  design  which  was  proven  in  the  first  step. 
Tuning  of  assignments,  code,  algoithras  and  structures  can  take 
place  in  the  host  environment  until  the  simulator  provides  a 
degree  of  confidence.  Load  modules  can  then  be  built  and  moved  to 
the  target  environment  or  to  a  target  test  bed  for  further  study. 
The  implementation  should  produce  an  effective,  understandable 
transformation  of  the  design.  The  automatic  generation  of 
appropriate  comments  in  the  source  code  can  ease  the  more  complex 
process  of  maintenance  in  a  distributed  environment. 


The  following  are  some  key  aspects  of  implementation: 

Standard  Interface  Set  to  a  Catalog  of  Runtime  Support  Environment 
Features  and  Options"  This  interface  set.  establishes  a  virtual 
Ada  machine.  The  compilation  system  produces  target  code  that 
uses  the  services  provided  by  the  standard  interface  set.  The 
requested  services  determine  which  modules  of  the  run  time  support 
library  are  to  be  exported  to  the  target  environment. 


Target  Network  Topology  Specifier.  This  allows  the  designer  to 
specify  the  symbolic  names  for  remote  area  networks,  local  area 
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identifies  the  communications  support  available  to  link  the 
various  entities  of  the  network. 


Target  Node  Resources  Specifier.  This  tool  allows  the  designer  to 
specify  the  hardware  resources  for  each  node  identified  with  the 
network  topology  specifier.  The  system  will  retain  this 
information  in  the  project  object  base  along  with  the  collection 
of  software  resources  that  will  be  assigned  to  this  node  later  in 
the  design.  The  designer  declares  the  instruction  set 
architectures  available,  the  memory  banks  and  their  attributes, 
the  buses  and  their  attributes,  and  the  communications  links  that 
are  available. 


Partioninq  and  Allocation  Tool.  After  the  Ada  source  code  has 
been  transformed  into  a  DIANA  representation  and  executed  to 
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demonstrate  that  it  meets  the  functional  requirements  of  the 
program,  a  discipline  of  comments  and  key  words  such  as  "location" 
can  be  used  to  map  each  program  entity  to  a  symbolic  location. 
This  symbolic  location  corresponds  to  those  node  and  network 
identifications  previously  entered  with  the  topology  specifier  and 
the  node  resource  specifier.  These  non-functional  requirements 
are  added  as  attributes  to  the  DIANA  representation. 


Distributed  Workload  Simulation.  After  the  symbolic  location 
assignments  and  other  constraints  have  been  added  to  the 
attributes  of  the  DIANA  representation,  the  workload  simulator 
examines  the  project  object  base  to  determine  characteristics  of 
the  already  existing  workload  (if  any)  and  to  select  empirical 
estimates  of  communication  delays,  processing  throughput,  and 
other  relevant  estimators.  A  simulation  is  then  provided  for 
analysis.  If  the  analysis  indicates  the  design  approach  is  not 
feasible,  new  approaches  to  distribution  can  be  provided  by 
returning  to  the  preceding  step. 


Distributed  Program  Building.  When  the  workload  simulation 
Indicates  a  feasible  design,  the  process  of  building  new  load 
modules  includes  examining  the  symbolic  location  assignments  added 
to  the  DIANA  tree  and  looking  these  up  in  the  project  object  base 
to  determine  what  type  of  instruction  set  architecture  the 
particular  entity's  object  code  is  to  be  generated  for.  If  the 
code  is  to  be  added  to  the  workload  of  an  existing  system,  it  is 
also  necessary  to  identify  if  additional  modules  or  new  versions 
of  the  run  time  library  need  to  be  added  or  if  additional  hardware 
is  likely  to  be  needed  to  accomodate  the  increase  in  workload. 
The  end  result  of  the  program  building  activity  is  to  prepare  a 
load  module  consisting  of  applications  code  and  the  necessary 
support  from  the  run  time  library  for  each  of  the  processors 
affected  by  the  distribution  of  the  pr^ram  entities. 


Hurt  Time  SwCDcrt  Er*. vi rcr.nic tsrir.n.  t #  i  i  fa  » n ^  nmnarfu  a  r a 
to  depend  upon  the  program  meeting  both  its  functional  and  its 
non-functional  requirements,  it  may  be  desirable  to  prepare  the 
program  for  execution  in  a  target  testbed.  To  be  effective,  the 
testbed  should  be  fully  instrumented  and  interact  with  the  host 
environment.  This  requires  the  support  of  a  run  time  monitor  for 
each  processor  in  the  target  testbed  to  interact  with  the 
instrumentation  and  the  host  environment  to  provide  meaningful 
information. 


Other  implementation  activities  are  similar  to  those  encountered 
in  a  system  which  generates  object  code  for  a  single  embedded 
processor. 

SUPPORTING  TOOLS 

Target  Network  Topology  Specifier.  This  tool  permits  the  topology 
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of  remote  area  networks*  local  area  networks  and  individual 
processing  nodes  to  be  identified  along  with  the  communication 
paths  linking  them  together. 

Target  Node  Resources  Specifier.  After  the  nodes  were  identified 
via  the  target  Network  Topology  Specifier,  this  tool  allows  the 
processors,  memory  resources,  bus  resources,  10  resources,  and 
communications  paths  available  to  each  node  (plus  their 
relationships  and  attributes)  to  be  specified.  This  system  will 
automatically  add  and  maintain  a  list  of  the  software  resources 
assigned  to  each  target  node.  This  information  is  maintained 
under  configuration  management  control  in  the  project  object  base. 

Partitioning  and  Allocation  Tool.  This  tool  uses  a  discipline  of 
"Ada  commenting  to  add  symbolic  information  concerning  the 
non-functional  requirements  of  the  program  (such  as  location 
assignment)  to  be  mapped  to  the  entities  of  an  Ada  program. 

Distributed  Workload  Simulator.  This  tool  reads  the  symbolic 
location  of  assignments  and  other  constraints  as  attributes  in  the 
DIANA  representation.  It  selects  estimators  of  the  impact  of  the 
non-functional  requirements  from  the  project  object  base,  and 
executes  a  simulation  of  the  program  to  permit  analysis. 

Distributed  Program  Builder.  This  tool  examines  the  attributes 
added  to  the  DIANA  representation  by  the  partitioning  and 
allocation  tool  and  uses  this  symbolic  information  to  look  up  the 
target  node  resources  in  the  project  object  base.  Prom  this 
information  it  selects  the  appropriate  back  end  code  generators 
for  the  processors  that  will  be  affected  by  the  distribution  of 
the  program  entities.  It  also  checks  to  see  if  additional  modules 
are  needed  from  the  run  time  library.  A  load  set  is  then 
generated  for  each  processor. 

Run  Time  Support  Environment  Monitor.  This  tools  executes  in  the 
run  time  environment  of  a  processor  either  in  a  target  testbed  or 
the  actual  target  system.  It  captures  and  reports  information 
releva.it  to  the  testbed  instrumentation  and/or  the  interactive 
host  environment.  The  information  is  generally  useful  in  studying 
the  behavior  of  the  system. 


Run  Time  Support  Dependencies  Analyzer.  This  tool  identifies  the 
run  time  library  modules  that  will  be  required  by  the  application 
object  code.  It  indicates  the  probable  impact  on  size  and 
throughput  based  upon  frequency  and  type  of  constructs  and 
referencing  from  a  table  of  empirical  data  that  is  improved  over 
time . 

Run  Time  Support  Timing  Analyzer.  This  tool  works  with  a  run  time 
monitor  to  provide  a  more  accurate  perception  of  the  timing 
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requirements  of  the  run  time  kernel,  the  run  time  library  modules, 
the  application-  code,  communications,  and  other  overhead. 


Run  Time  Support  Storage  Analyzer.  This  tool  works  with  the  run 
time  monitor  to  provide  insight  into  the  manipulation  of  both 
statically  and  dynamically  determined  storage  requirements.  The 
information  is  particularly  useful  in  evaluating  program  units  for 
their  storage  utilization.  It  can  provide  summaries  and  warnings 
for  inappropriate  utilization. 

Run  Time  Support  Tasking  Analyzer.  This  tool  evaluates  tasks  for 
interactions  with  other  tasks  creating  static  tasking  profiles. 
This  can  be  used  with  run  time  monitoring  in  detecting  deadlock 
and  other  tasking  interaction  failures.  It  can  also  be  used  in 
analyzing  the  static  scheduling  of  tasks  as  well  as  their  dynamic 
performance . 

Distributed  Target  Node  Restriction  Checker.  In  an  incrementally 
evolving  system,  many  target  nodes  acquire  additional  or  changed 
workload  assignments  over  time.  Because  of  restrictions  placed  by 
the  processor  design  on  available  memory  and  because  of  other 
restrictions  such  as  representation  specifications  which  assign 
certain  10  devices  to  particular  addresses,  this  tool  checks  to 
see  if  the  additional  workload  proposed  for  the  node  will  conflict 
with  these  restrictions. 

Distributed  Program  Resource  Sharing/Replication  Analyzer. 
Frequently,  communications  overhead can  be  reduced  and  throughput 
increased  by  deliberately  replicating  many  resources  in  a 
distributed  program  (eg,  constants,  common  .processing  routines). 
This  tool  assists  the  designer  in  determining  the  options  and  the 
potential  affects  of  resource  sharing  versus  replication. 

Upgrade  Load,  Test  and  Integration  Planning  Aid  for  Non  Stop 
Nodes .  Frequently,  a  large  complex  distributed  network  such  as 
the  SSP  will  require  a  number  of  non-stop  services.  Unattended 
satellites,  unattended  free  flying  platforms,  and,  often,  attended 
locations  where  life  and  property  depend  upon  a  continuous 
provision  of  the  sevices,  will  require  interactive  testing  with 
the  host  environment.  Upgrades  and  reconfiguration  should  be  able 
to  take  place  dynamically  without  bringing  the  system  to  a  stop. 
While  the  experts  know  how  to  accomplish  these  functions,  a 
planning  aid  is  useful  to  prepare  for  the  transition.  This  tool 
serves  as  such  an  aid. 

DIANA  Tree  Browser.  This  tool  is  useful  in  supporting  the 
maintenance  of  other  tools  such  as  the  partitioning  and  allocation 
tool  and  in  supporting  the  evolution  of  additional  tool 
functionality. 
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DIANA  Tree  Expander.  This  tool  complements  the  browser  and 
provides  for  adding /modify ing  DIANA  representations. 

Fault  Tolerance/Safety  Analyser  and  Simulator.  Fault  tolerance 
and  software  safety  are  of  particular  concern  in  multiprocessor 
and  distributed  applications.  Fortunately#  not  all  subsystems  and 
not  all  programs  require  the  extra  overhead  associated  with  fault 
tolerant  software.  However  for  those  programs  that  do  require 
fault  tolerance  and  software  safety  analysis#  this  tool  can  be 
in-valuable. 

Fault  Tolerance  Programmers  Aid.  This  tool  assists  the  programmer 
In  developing  fault  tolerant  programs  for  distributed, 
multiprocessor#  and  single  processor  applications. 

Real  Time  Programmers  Aid.  This  tool  aids  the  designer  in 
designing  hard  scheduled,  real  time  programs  to  map  to 
distributed#  multiprocessor#  and  single  processor  applications. 

Expert  System  Generator.  This  tool  assists  the  programmer  in 
generating  experts  systems  that  can  co-exist  with  the  applications 
code  in  distributed#  multiprocessor#  and  single  processor 
applications . 

Impact  Analyzer  for  Module  Changes.  This  tool  allows  the  designer 
to  ask  "what  if"  types  of  questions.  Specifically,  the  impact  of 
changing  an  interface  specification  or  of  changing  the  definition 
of  a  private  type  can  be  quickly  identified. 

Analyzer  for  Elaboration  Dependencies.  The  Ada  language  rules 
allow  For  partial  elaboration  to  be  ordered.  This  can  be 
particularly  troublesome  when  the  elaboration  takes  place  across  a 
distrubuted  collection  of  computing  resources.  This  tool  analyzes 
these  effects. 

Compilation  Order  Analyzer.  This  tool  reads  any  collection  of 
source  files  and  generates  a  report  of  the  order  of  required 
compilation. 

Intelligent#  Automated  Recompilation.  The  Ada  language  rules 
state  that  any  changes  in  the  public  specification  of  a  package 
may  cause  a  need  to  recompile  those  programs  dependent  upon  the 
package.  However  if  the  change  is  to  add  a  new  function  without 
modifying  any  of  the  existing  functions  or  interfaces,  then  many 
of  those  modules  that  use  this  package  may  not  have  to  be 
recompiled.  Similarly  if  the  change  is  to  a  single  function  that 
was  not  used  by  many  of  the  other  modules,  recompilation  can  again 
be  minimized.  This  tool  provides  automated  recompilation  when  the 
rules  are  obvious.  It  notifies  the  user  when  there  are  questions 
requiring  human  judgement. 
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Call  Tree  Analyzer.  This  tool  produces  a  report  showing  all 
resources  that  a  given  program  module  calls  and  is  called  by. 
Both  direct  and  indirect  calls  are  indicated  with  a  brief 
description  of  each  reference* 

Execution  Metrics  Analyzer*  This  tool  provides  relative 
statistical  analysis  of  the  execution  of  a  program  in  the  host 
environment • 

Cross  Reference  Analyzer.  This  tool  provides  the  standard  cross 
reference  listing  for  one  or  more  program  units.  All  references 
to  declarations  in  a  program  unit  from  anywhere  in  the  program 
space  are  shown. 

Statement  Profile  Generator.  This  tool  profiles  the  utilisation 
of  selected  Ada  constructs  in  an  identified  program  module. 

Generic  Instantiation  Analyzer*  This  tool  allows  the  user  to 
locally  instantiate  a  version  of  the  generic  reuseable  component 
and  to  test  the  version  with  defined  test  values.  If  the  locally 
instantiated  version  works  as  expected,  the  user  then  feels  more 
secure  in  utilizing  the  instantiation  inside  his  source  code 
modules. 

Generic  Instantiation  Reporter.  This  tool  reports  on  all  generic 
reusable  components  that  have  been  instantiated  since  the  module 
was  added  to  the  reusable  components  library.  It  also  reports 
other  relevant  data  about  the  forms  of  the  instantiations* 

Reusable  Components  Designers  Aid.  This  tool  assists  the  designer 
in  designing,  developing,  verifying,  and  documenting  components  to 
be  proposed  for  validation  and  inclusion  in  the  reusable  library. 
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The  most  important  requirements  and  opportunities  for  the  SSE  life 
cycle  project  object  base  become  evident  from  this  phase.  The 
results  are  summarized  below: 

Baselined  Products.  The  functional  requirements  are  similar  to 
those  described  in  the  preceding  sections.  However,  opportunities 
arise  dueto  the  requirements  for  the  DIANA  representation  in  the 
implementation  phase.  An  estimated  ten  to  twenty  times  the 
processing  time  is  required  to  convert  Ada  source  code  to  DIANA 
representation  as  compared  to  converting  the  DIANA  representation 
to  object  code  for  the  the  target  environment.  Furthermore  source 
code  and  object  code  can  both  be  reconstructed  from  the  DIANA 
representation.  Since  the  Stoneman  requirements  for  the  MAPSE 
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provides  a  unique  identification  for  each  object  produced  (which 
includes  history  attributes  identifying  the  time,  date,  tools, 
etc.  used  to  manipulate  the  object),  an  enormous  amount  of  on-line 
storage  space  can  be  conserved  in  the  project  object  base  if  the 
DIANA  representation  is  maintained  in  the  baseline. 

The  other  important  implication  for  baseline  control  as  a  result 
of  this  phase  is  the  identification  and  maintenance  of  the  network 
topology  and  the  network  node  resources  described  in  the  preceding 
tools  and  methods. 

Non-Baselined  Data.  The  temporary  storage  required  for  this 
category  is  similar  to  the  functional  requirements  listed  in  the 
other  sections  of  this  report.  However,  the  savings  and  storage 
space  made  possible  by  the  utilization  of  a  DIANA  representation 
described  above  may  be  significant  even  for  temporary  storage 
requirements . 

Measurement  Data.  A  number  of  metrics  regarding  the  utilization 
of  these  tools  is  desirable.  Knowing  who  is  using  the  tools  for 
what  projects,  and  knowing  the  frequency  of  reference  can  provide 
valuable  management  insights. 
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APoluino  Denotationai  Semantics  to  Soecifuino  Kernel  Interfaces 

R.S.  Freedman 

Department  of  Electrical  Engineeing  and  Computer  Science 
Polytechnic  University 
Route  1 10  Fermingdale  NY  1 1735 
Freedman  9  ADA20 

1.  Deriotationel  Semantics:  Pragmatics 

The  deriotationel  approach  to  formal  semantics  involves  specifying 
abstract  mathematical  meanings  to  objects,  in  such  a  wag  that  the 
meanings  of  the  objects  are  modelled  by  the  mathematical  abstractions. 
The  mathematical  entities  that  are  used  for  this  purpose  (the  denotations) 
are  well-understood  classes  of  sets  and  functions.  The  denotationai 
approach  is  suitable  for  modelling  machine-independent  meanings  because 
of  its  emphasis  on  mathematical  constructs.  Consequently,  the 
denotationai  approach  has  frequently  been  used  for  the  formal 
implementation-independent  specification  of  programming  languages,  and 
for  deriving  rules  for  proofs  of  program  properties  (an  axiomatic 
semantics). 

The  essential  idea  in  a  denotationai  semantics  is  to  map  the 
syntactical  structures  (some  sets  and  functions)  of  a  language  onto  some 
semantic  structures  (other  sets  and  functions).  This  is  done  so  that  every 
legal  program  in  0  language  can  be  mapped  into  its  meaning.  The  approach 
usually  taken  is  to  recursively  describe  the  semantics  of  a  construct  in 
terms  of  its  sub-constructs.  The  use  of  the  denotationai  approach  is 
applicable  to  certain  types  of  sets,  called  domains,  in  order  to  insure 
convergence  in  the  recursive  application  of  functions.  The  formal 
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mathematics  of  this  approach  was  presented  by  [Scott  and  Strachey] 

There  are  several  notations  (or  "meta-languages”)  for  specifying  a 
denotattone!  semantics.  The  most  common  one,  used  by  (Tennentl,  [Gordon] 
and  iStoyl  is  a  variant  of  Lambda  Calculus.  This  notation,  while 
mathematically  precise,  is  hard  to  read  by  many  programmers  and  language 
Implemented.  Other  notations  that  have  also  been  proposed  include  the 
"Ada-like"  notation  in  the  Ada  Formal  Semantic  Definition  [INRIAJ,  and  the 
notations  developed  in  the  Vienna  Definition  Method  [Bjorner], 

Many  of  these  notations  have  automated  facilities  that  help  evaluate 
end  sequence  a  large  number  cf  recursive  function  calls  that  stablish  the 
meaning  of  a  construct.  For  example,  (Kini  et  al]  has  developed  tools  for 
testing  the  denotational  semantic  definitions  of  prograrnrnong  languages, 
as  long  as  these  languages  are  defined  in  AFDL+  (an  extension  of  the  INRIA 
notation).  [Mossess]  has  also  developed  the  Semantics  Implementation 
System  based  on  the  notation  in  [Gordon],  These  systems  run  programs 
that  'execute"  the  meta-language  equations  that  define  the  semantics  of  a 
construct.  In  one  sense,  development  of  these  tools  results  in  an 
operational  semantics  of  a  construct. 
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programming  languages,  compilers  [Clemmensen],  interpreters  [Stoy],  and 
.databases  [Bjorner],  There  is  also  a  formal  specification  of  concurrency 
presented  using  denotational  semantics  [Clinger],  Some  of  the  issues 
involved  with  specifying  kernel  facilities  based  on  the  denotational 
approach  were  first  addressed  in  [Freedman  1962]  and  [Freedman  1935].  In 
the  following  sections,  we  show  what  is  entailed  to  develop  a  denotational 
semantics  for  kernel  interfaces. 
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2.  Denotations!  Semantic  Domains 

The  denotetional  semantics  of  a  kernel  interface  language  consists  of 
the  semantics  of  procedure  and  function  calls,  as  well  as  the  semantics  of 
expression  evaluation.  In  order  to  create  this  denotational  semantics,  we 
need  to  specify  the  following  components: 

Syntactic  Domains 
Syntactic  Clauses 
Semantic  Domains 
Semantic  Functions 
Semantic  Clauses 


The  syntactic  domains  of  a  language  consists  of  different  syntactic 
categories  that  may  be  assigned  meaning.  These  categories  may 
(recursively)  define  other  categories;  to  assure  convergence,  domains  ere 
specified.  Some  examples  of  syntactic  domains  are  a  domain  of 
identifiers,  a  domain  of  commends,  and  a  domain  of  expressions.  For  CAIS 
interfaces,  these  domains  consist  of  identifiers,  expressions,  commends, 
end  declarations. 


The  syntactic  clauses  show  how  s  syntactic  category  may  be 
described  in  terms  of  sub-categories.  For  example,  one  clause  may  specify 
that  ell  kernel  interface  commands  have  the  form: 


C  ::=  operi(E)  I  close(E) 


where  E  is  in  the  domain  of  expressions.  The  notation  for  syntactic 
clauses  usually  follows  the  notation  for  specifying  the  concrete  syntax 
(phrase  structure)  of  a  language.  However,  since  only  the  meaning?  of 
constructs  end  sub-constructs  are  emphasised,  and  not  how  a  construct  is 
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formed,  this  type  of  syntax  is  termed  the  abstract  syntax. 

The  semantic  domains  consist  of  well-understood  domains  that  are 
either  given  (like  the  domain  Bool  =  {TRUE.  FALSE}  )  or  are  constructed 
from  other  domains.  These  domains  are  the  actual  'denotations*  for  our 
semantics.  The  most  important  of  these  domains  are  the  Environment,  the 
Store,  and  the  Continuation  domains.  For  example,  an  Environment  domain 
may  described  by  the  domain  of  functions  from  the  domain  of  identifiers 
Ide  to  the  domain  of'denotable  values  Dv,  or 
Env  =  Ide  -->  Dv 

The  domain  of  denotable  values  must  be  defined  in  turns  of  other  domains: 
the  denotable  values  usually  contains  the  domain  of  locations.  The 
Environment  is  changed  by  the  elaboration  of  definitions.  Stores  may  be 
described  by  the  domain  of  functions  from  the  domain  of  Locations  Loc  to 
the  domain  of  Storable  Values  Sv,  or 
Stores  =  Loc  -->  Sv 

Stores  are  changed  by  the  execution  of  cornrnandsThe  continuation  domains 
may  be  described  by  functions  from  ’intermediate  results’  to  "final 

N. 

results."  Final  program  results  are  usually  expressed  in  terms  of  the 
Store  domain  For  example,  since  the  effect  of  executing  a  command  is  to 
change  the  Store,  the  domain  of  command  continuations  is  defined  by 
ComCont  =  Store  -->  Store 

As  another  example,  since  the  eff  .ct  of  evaluating  expressions  is  a  value 
and  a  store  (from  possible  "side-effects"),  the  domain  of  expression 
continuations  1$ 

ExpCorit  =  (  Dv  x  Store]  — >  Store 
The  above  expression  may  also  be  written  as 

ExpCorit  =  (  Dv  — >  Store  ]  -->  Store 

and  also  as 


ExpCont  =  Dv  -->  Store— >  Store 
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This  particular  form  of  function  notation  (the  ‘curried*  form)  Is  what 
makes  traditional  denotations!  semantics  difficult  to  read. 

The  semantic  functions  are  functions  that  specify  the  denotation  of 
the  syntactic  domain  constructs  in  terms  of  the  semantic  domain 
constructs  For  example,  the  semantic  function  for  expressions  may  be 
E:  Exp  —  >  Env  -->Slore  -->  Dv 


This  expresses  the  fact  that  the  semantics  of  “evaluating  an  expression’  is 
a  value  that  depends  on  an  environment  and  a  store.  Semantic  functions 
are  defined  for  all  syntactic  domains. 

The  actual  semantics  for  the  constructs  that  range  over  all  syntactic 
domains  are  defined  by  semantic  clauses.  A  semantic  clause  is  a  semantic 
function  definition  for  a  particular  syntactic  construct.  In  one  sense,  the 
semantic,  functions  form  specifications,  while  the  semantic  clauses 
actually  ‘implement’  the  semantics.  For  example,  the  evaluation  of  the 
expression  "1  =  1"  denotes  TRUE,  given  an  arbitrary  store  s,  and  an  arbitrary 
environment  u: 


E  [  1  =  1]  u  s  =  TRUE 

Semantic  functions  traditionally  utilize  square  brackets  around  syntactic 


consti  ucts  to  li'ici  ease  readability. 


Other  notation 


for  semantic  clauses 


may  correspond  to  more  familiar  programming  language  syntax.  For 
example,  in  the  AFDl  (inria)  'Ada-like'  notation,  the  semantic  function  E 
for  expressions  may  be  represented  as 

function  EVAL_EXPRESSION  ( T:  Syntex_Tree;  Eri:  Environment,  S:  Store) 
return  Oeriotable„Velues; 

The  semantic  clauses  for  all  expressions  would  correspond  to  the  function 

bodies  of  EVA! _ EXPRESSION,  for  all  possible  elements  of  Syntax_Tree. 

The  disadvantage  of  this  notation  is  its  ineconomy:  other  functions  (and 
the  non-Ada  like  ‘function  type')  must  be  defined  to  achieve  ell  meanings 
of  the  functional  notation  form  for  E.  For  example.  E  [  open  (El, 12,13, E4)  ] 
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u  is  q  function,  not  o  value. 

7.2.  An  example  of  Denotational  Semantics  for  the  Specification  of  Kernel 
Interfaces 

We  provide  an  example  of  the  denotational  approach  to  describe  the 
kernel  interfaces  of  CAIS  package  Node-Management.  This  example  shows 
the  beginning  specification  that  must  be  specified  for  a  denotational 
semantics:  the  domains  Node  and  Asv,  as  well  as  most  semantic  clauses 
are  left  incomple'e. 

Kernel  Facility:  package  Node-Management 

C  I  IkI  I  A  r\  r  •'A  ^  M  A 

jtjiitULU^  UUIIIQIUd 

icle  The  domain  of  identifiers  with  elements  1 1,12, ... 

Exp  The  domain  of  expressions  with  elements  El,  E2,.„ 

Com  The  domain  of  commands  with  elements  Cl,  C2,... 

Dec  The  domain  of  declarations  with  elements  D I, D2,... 

Syntactic  Clauses 

C  ::=  Open  (E1,I2,13,E4); 

I  close  (11,12,13,14); 

I  change-intent  (I1,I2,E3), 

I  copy_node(l  1,12,13,14); 

I  copy-tree  (11,12,13,14); 

I  rename  (I1,I2.!3,E4); 

Mink  (E 1  ,E2); 

literate  (1 1,I2,I3,E4,E5,E6); 

I  get_next  (II, 12), 

1  set_current_node  (E 1  ,E2), 

I  get_current_node  (I  0; 
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E  ::=  Is— open  (1 1 ) 

I  kind  (ID 
I  primary_narne  (ID 
I  primary^key  (ID 
I  prim0ry_relation  (ID 
IpaUukeyOD 
I  path-relation  (11) 

I  ootamahle  (II,  12,  E3) 

I  more  (ED 
I  is.  'mes:i,E2) 

D  ::=  .11:  node-iterator  ; 

i  il:  reiationsr?ip_key_paUern  :=  LI, 

111:  relatlon-name_pattern  :=  E 1; 

Semantic  Domains 

Env  The  domain  of  environments  with  elements  u: 

Env  =  ide  — >  (Dv  +  {unbound}) 

Dv  The  domain  of  denotable  values  with  elements  d: 

Dv  =  loc  +  Asv  +  Cc  (Exceptions  are  denotable.) 

Loc  The  domain  of  locations  with  elements  1. 

Asv  The  domain  of  assignable  values  with  elements  a. 

Store  The  domem  of  stores  with  elements  s: 

Store  =  Loc  — >  (Sv  ♦  (unused)) 

Sv  The  domain  of  sto.  able  values  with  elements  v 
Sv  =  Node  +  Asv 

Node  The  domain  of  nodes  with  elements  n. 

Cc  The  domain  of  command  continuations  with  elements  c: 
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Cc  =  Store  —  >  Store 

Ec  The  domain  of  expression  continuations  with  elements  k. 

Ec  =  Dv  -“>  Cc 

Dc  The  domain  of  declaration  continuations  with  elements  d: 

Dc  =  Env  Cc 

Semantic  functions 

Semantics  of  expressions: 

E:  Exp  —  >  Env  —  >  Ec  — >  Cc 
Semantics  of  commends: 

C:  Com  —  >  Env  —  >Cc  —  >Cc 
Semantics  of  declarations: 

D:  Dec  —  >  Env  — >  Dc  — >  Cc 
Semantic  Clauses  (some  examples) 

Commands 

C  i  open  (E1.I2.I3.E4)  ]  u  c  =  {meaning} 

Expressions 

E  [  is_open  (M)  ]  u  k  =  {meaning} 

Declarations 

DIM:  nodeJterator  ]  u  d  =  {meaning} 

3.  Analysis  of  Denotations!  Approach 

The  denotational  approach  to  formal  semantics  can  adequately  specify 
kernel  interfaces,  provided  one  interprets  these  interfaces  as  defining  a 
language.  The  complete  specification  of  CA!S  semantics  for  storage 
management  arid  input/output  can  also  he  expressed,  although  it  would  be  a 
laborious  undertaking,  even  if  aided  by  automated  tools.  The  major  tasks  in 
these  areas  involves  selecting  a  formal  mathematical  model  for  the  CAiS 
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data  structures  and  devices.  These  formal  models  would  then  he 
represented  ir«  the  notation  chosen  for  the  domains.  Semantics  for  process 
management  can  also  be  described  in  the  denotational  style,  assuming  that 
a  formal  model  of  concurrency  (like  Actor  Semantics)  is  also  similarly 
selected. 

The  denotational  approach  is  not  an  alternative  method  to  specifying 
semantics,  rather,  it  emphasizes  a  different  perspective  toward 
specification.  The  denotational  approach  corresponds  to  a  "top-down" 
solution  to  the  problem  of  defining  a  language:  the  emphasis  Is  on 
developing  mathematical  domains  and  functions  to  model  machine 
meanings  resulting  from  program  execution.  The  operational  approach 
corresponds  to  a  "bottom-up*  solution,  whereby  the  emphasis  is  on 
constructing  machine  operations  that  will  execute  programs.  An 
algebraic  semantics  is  also  a  denotational  semantics,  in  this  approach, 
other  specific  mathematical  constructs  ere  used  (more  specific  then 
domains)  for  representing  the  denotations.  As  observed  above,  a 
denotational  specification  becomes  an  operational  specification  if  tools 
ere  provided  that  can  “execute"  the  denotational  semantic  notation.  Both 
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axiomatic  semantics. 

It  is  not  clear  which  approach  is  best  for  the  specification  of  kernel 
interfaces.  An  operational  approach  would  probably  easier  to  understand 
(but  harder  to  modify  or  check  for  consistency  or  completeness)  then  a 
denotational  specification;  conversely,  a  denotational  specification  is 
more  amenable  to  a  machine  independent  meaning.  This  last  characteristic 
Is  important  for  achieving  interoperability  and  transportability.  On  the 
other  hand,  the  use  of  denotational  semantics  for  the  specification  of 
concurrent  computation  in  Ada  has  not  been  as  adequately  addressed  as  in 
some  other  languages;  this  implies  that  for  process  management,  at  least 
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many  researchers  ere  more  comfortable  with  an  operational  approach. 
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ABSTRACT 


Throughout  the  development  of  the  CAIS,  semantics  has  continued  to  be  an  issue.  Aside 
from  the  benefit  to  designers,  having  a  formal  description  of  an  operating  system  interface,  such  as 
CALS,  is  important  to  CAIS  standardization  and  transportability  of  software  using  the  CAIS. 
Although  validation  systems  for  kernel  interfaces  are  now  being  developed,  the  community  has 
largely  ignored  kernel  interface  verification.  Constructing  proofs  of  systems  that  use  a  kernel 
clearly  depends  on  a  formalism  for  the  kernel  In  this  paper,  various  methods  of  description  are 
analyzed  regarding  their  applicability  to  kernel  interfaces.  The  methods  treated  include  English 
narrative,  abstract  machines,  axiomatics,  and  denotational  descriptions.  For  each  method,  we 
show  an  example  from  CAIS  and  analyze  the  methods  applicability  to  various  features. 

Keywords.  Kernel  interfaces,  operating  systems,  verification,  axiomatic  and  denotational 
semantics. 


c 

I 

8 

K 

! 

I 

I 

8 

8 

8 

8 

8 

8 

8 

8 

I 

8 

I 

8 


1.  INTRODUCTION 

This  paper  describes  and  evaluates  alternative  methods  of  specifing  the  semantics  of  kernel 
level  facilites.  Both  formal  semantic  methods  and  informal  methods  are  examined.  The  authors 
have  been  involved  with  an  effort  to  develop  a  common  set  of  services  to  support  APSE  (Ada** 
Programming  Support  Environment)  tools.  The  methods  we  describe  are  exemplified  using  this 
common  set,  called  CAIS  (Common  APSE  Interface  Set,  pronounced  as  case).  CAIS  is  an 
operating  system  interface  that  supports  software  development  tools. 

If  CAIS  is  implemented  on  a  variety  of  host  systems  then  the  effort  needed  to  transport  tools 
will  be  reduced.  In  the  same  manner  as  for  the  Ada  Language,  a  validation  capability  is  being 
developed  for  the  CAIS  [E&V  85).  Validation  must  address  the  consistency  and  completeness  of 
CAIS  implementations  with  respect  to  the  specification.  In  doing  preliminary  work  on  developing 
validation  tests,  we  found  the  need  for  a  precise  specification  of  the  system.  Various  specification 
methods  have  been  examined  for  their  applicability  to  CAIS  features.  In  this  paper,  we  present  and 
compare  the  applicability  of  each  method 
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benefit  of  formai  description  is  clear.  Any  effort  to  standardize  on  a  low  level  interface,  such 


graphics  or  process  management,  needs  a  precise  specification  to  be  complete  enough  and 
unambiguous.  As  standards  arise,  we  are  seeing  the  development  of  validation  mechanisms  to 
assure  consistency  among  implementations,  as  mentioned  above  with  CAIS.  It  has  also  become 


clear  that  formal  specifications  can  be  used  to  direct  implementation  efforts.  Technology  is 
advancing  to  the  point  where  directed  implementations  are  as  efficient  as  ad  hoc  implementations. 


2.  CAIS:  A  COMMON  OPERATING  SYSTEM  INTERFACE 
In  order  to  control  the  high  cost  of  software  that  is  embedded  in  military  systems,  the 
Department  of  Defense  has  developed  and  is  in  process  of  standardizing  on  a  single  programming 
language  called  Ada.  The  cost  savings  will  be  realized  not  only  from  software  engineering  features 
of  the  language,  but  also  from  the  fact  that  a  single  standard  will  permit  the  reuse  of  operational 
software  and  software  development  tools. 

When  tools  are  considered,  however,  a  single  language  is  only  part  of  what  is  needed  for 
transportability.  Another  requirement  is  a  compatible  operating  system.  APSE  tools  access 
environment  data  and  control  processes  through  operating  system  services.  The  combination  of  a 
standard  language  and  a  standard  operating  system  would  increase  tool  transportability. 


*Ada  is  a  registered  trademark  of  the  U.S.  Government  Ada  Joint  Program  Office. 
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>  Since  there  are  many  diverse  systems  in  use  today,  a  single  operating  system  is  not  feasible, 
but  something  almost  as  good  can  be  achieved.  CAIS  defines  a  common  interface  to  the  operating 
system.  The  interface  is  a  set  of  Ada  packages  containing  subroutines  and  data  definitions  that  are 
used  by  Ada  programs  to  request  system  services.  Implementations  of  CAIS  may  be  constructed 
effectively  on  a  variety  of  existing  operating  systems.  If  the  format  of  the  call  for  services  (syntax) 
is  standard  and  the  response  to  the  call  (semantics)  is  the  same,  then  the  effect  of  a  standard 
operating  system  has  been  achieved. 

CAIS  has  been  designed  by  a  working  group  of  the  KIT/KmA  (Kernel  APSE  Interface 
Team/Industry  and  Academic)  under  sponsorship  of  the  Ada  Joint  Program  Office  through  Naval 
Ocean  Systems  Center  [KIT-82].  A  Government  Standard  CAIS  specification  [CAIS-85]  is 
currently  being  reviewed,  and  an  effort  will  soon  be  underway  to  address  incorporating  capabilities 
deferred  from  the  design,  such  as  distributed  environments.  Several  prototypes  and 
implementations  are  currently  being  developed. 

3.  SPECIFYING  KERNEL  FACILITIES 

3.1  Define  Semantics  and  Syntax 

A  typical  CAIS  facility  is  the  OPEN,  procedure,  whose  format  is  shown  in  Figure  1.  The 
procedure  specification  gives  the  procedure  name,  the  keywords,  the  necessary  punctuation,  and 
the  parameters.  This  format  is  the  syntax.  The  CAIS  document  accompanies  the  procedure 
specification  with  English  narrative  telling  what  happens  when  the  call  is  executed.  The  description 
of  what  OPEN  does  is  semantics.  The  usage  of  words  in  this  context  follows  the  usage  in  English 
grammar  where  syntax  is  the  format  of  the  sentence  and  semantics  is  their  meaning. 

procedure  OPEN(NODE:  in  out  NODETYPE; 

NAME:  in  NAMESTRING; 

INTENT;  in  INTENTION :« (1  »  READ); 

TIMELIMIT:  in  DURATION  :■  NODELAY); 

Figure  1.  The  OPEN  facility’s  syntax. 

Ada  provides  a  well  understood  notation  that  completely  and  unambiguously  defines  syntax. 
Ada  semantics  are  conveyed  in  English  text  and  the  Language  Reference  Manual  states  that 
meanings  are  as  defined  in  Webster's  Dictionary.  Text  benefits  from  the  power  and  suffers  from 
the  ambiguities  of  a  natural  language  specification.  The  English  description  is  adequate  for  most 
purposes  but  is  often  incomplete  and  ambiguous. 

One  example  is  the  OPEN  statement  of  Figure  1.  Its  function  is  to  create  an  association 
between  an  Ada  program  variable  and  a  CAIS  environment  node.  The  internal  variable,  called  a 
node  handle,  is  used  by  the  program  to  reference  the  node  in  operations.  One  parameter  to  OPEN 
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is  an  array,  called  INTENT,  that  conveys  intended  access.  Typical  values  of  Intent  arc  Read, 
Write,  and  ExclusiveRead.  As  an  example  of  incompleteness,  the  explanation  of  OPEN  does  not 
indicate  behavior  if  the  Intent  array  contains  overiaping  or  contradicting  interns.  What  if  both  Read 
and  ExclusiveRead  are  requested?  No  semantics  are  defined  in  this  case.  Natural  language 
specifications  contain  implied  assumptions  about  their  context.  An  implied  assumption  of  the  open 
statement  may  be  that  a  user  doesn't  care  which  one  of  a  contradicting  intents  is  chosen.  Such  a 
SMeifteatWi  specification  may  be  precise  enough  for  a  user  but  not  for  validating,  implementing,  or 
arguing  tormally  about  programs  using  CAIS.  Semantics  of  CAIS  are  mostly  well  defined, 
however,  one  can  anticipate  uses  requiring  a  more  thorough  or  formal  description. 

3 3  Methods  of  Supplementing  a  Semantic  Definition 

The  semantics  of  CAIS  is  specified  in  MIL-STD-CAIS  by  English  narrative,  with  some 
additional  semantics  implied  by  the  Ada  package  specifications.  The  methods  investigated  for 
supplementing  CAIS  semantics  can  also  be  grouped  into  formal  and  informal  methods.  The  formal 
methods  are  mathematical  in  nature  and  include  axiomatic,  denotational,  and  abstract  machine 
notations.  The  informal  methods  are  additional  narrative  and  examples. 

4.  INFORMAL  SEMANTIC  SPECIFICATION 

The  informal  methods  of  supplementing  semantics,  English  narrative  and  examples,  have 
strong  points  and  weak  points.  English  or  other  natural  language  narratives  can  be  verbose, 
ambiguous,  and  context  dependent  The  interpretation  of  an  English  sentence  depends  on  the 
background  of  the  reader.  Further,  English  words  have  many  meanings.  My  dictionary  lists  12  for 
"be",  33  for  "beat",  and  15  for  "bend".  There  is,  however,  no  match  for  the  undcrstandability  and 
generality  of  English.  Even  texts  in  theoretical  mathematics  use  more  English  than  mathematical 
notations  to  communicate. 

■uescnpuon  oy  LA^jupict  is  dene  through  small  programs  or  parts  of  programs  using  CAIS. 
Test  cases  from  a  CAIS  test  suite  would  make  good  examples  since  these  are  small  programs 
exercising  one  CAIS  feature.  Examples  are  not  general  and  not  concise  but  arc  very 
understandable.  When  there  is  a  choice  of  methods  of  specifing  semantics  the  most  precise, 
concise,  and  abstract  method  should  be  used.  Formal  mathetical  methods  ,  when  they  are 
applicable,  usually  meet  these  criteria.  But  there  are  still  many  cases  where  informal  methods  arc 
needed.  The  informal  methods  are  supplements  and  not  replacements  for  formal  methods. 
Examples  of  the  use  of  informal  methods  to  supplement  CAIS  semantics  follow. 

4.1  OPEN  Facility 

OPEN,  as  discussed  above,  establishes  a  connection  between  an  external  file  and  an  internal 
node  handle.  Objects  in  CAIS  are  managed  using  a  node  model.  A  node  can  be  a  file  node,  a 
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structure  (directory)  node,  or  a  process  node.  Figure  2  is  an  example  of  the  use  of  OPEN.  It  is  a 
test  case  showing  how  an  internal  program  variable  called  a  node  handle  is  connected  to  an  external 
node  by  OPEN.  The  handle  is  then  used  to  access  the  node.  The  example  shows  semantics  in  the 
sense  that  it  shows  how  the  OPEN  procedure  is  used. 

Examples  may  not  show  what  happens  in  any  of  the  exceptional  cases.  Supplementary 
english  narrative  can  be  added  showing  what  happens  if,  for  example,  incompatible  Intents  are 
presented  to  the  procedure.  The  Intent  array  argument  to  OPEN  could  be: 

(READ,  WRITE,  CONTROL) 

There  is  nothing  to  stop  a  user  from  specifing  an  incompatible  set  of  intents.  If  both 
WRITE  and  EXCLUSIVEWRITE  arc  specified  there  is  a  conflict.  The  first  Intent  lets  many  users 
write  simultaneously  and  the  second  permits  only  one  at  a  time.  This  uncertainty  can  be  resolved  by 
additional  narrative  in  the  specification  such  as: 

1.  In  the  event  of  conflict  use  the  most  restrictive  interpretation;  thus, 
EXCTUSP/EWRITE  has  precedence  over  WRITE,  or 

2.  In  the  event  of  conflict  reject  the  call  with  an  exception  or 

3.  Any  conflict  resolution  scheme  is  acceptable. 

Any  one  of  the  above  clarifications  is  sufficient  from  the  viewpoint  of  creating  validation 
tests.  Which  one'  is  chosen  is  a  design  issue,  however,  without  specifying  one  operdon,  the 
validator  is  forced  to  make  the  design  decision. 


Applying  Semantic  Description  Techniques  to  Kernel  racilides 


-  CAIS  TEST  OF  OPEN 

-  Open  by  Name  -  good  data  -  take  defaults 

m 

—  Open  the  nods  and  verify  with  an  inquiry 

—  Precondition  -  Initial  State  1 


with  Node_Mcnagement,  use  Node.Management; 
with  Node.Oefinitions;  use  Node.Definitions; 
with  TextiO;  use  TextiO; 
procedure  Gpenl  Is 
Nodel:  Node_Typ«; 

Name:  Namestring; 
begin 

-  OPEN  THE  NODE - 

Name  ut  "TOT(FI)"; 

Oper.(Node1,  Name) 

PutLine  ("Open  has  been  called"); 

Verify  with  an  Inquiry  ■ — 
if  ls_Open(Node1)  then 
PutUne  ("Open  Verified"); 

else 

PutUne  ("Open  Failed"); 
end  if; 

-  END  OF  TEST - 

end  opent; 


Figure  2  Example  of  Open  Procedure 
4.2  The  CAIS  Node  Model 

Nodes,  node  handles,  and  path  names  are  pan  of  the  node  model.  CAIS  manages  files, 
directories,  devices,  and  processes  by  representing  them  as  nodes  in  a  network.  Nodes  are  related 
to  each  other  by  relationships.  Relationships  are  uniquely  specified  by  a  relation  name  and  a 
relationship  key,  and  a  relationship  may  be  either  primary  or  secondary.  Primary  relationships  are 
constrained  to  maintain  a  hierarchical  structure  of  nodes.  A  typical  network  is  shown  in  Figure  3. 


Arrivin':  Scmanti 
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Figure  3.  The  Node  ModeL 

An  object,  such  as  a  file,  is  found  by  following  the  path  of  relationships  from  a  known  node 
to  an  object  node.  A  path  is  specified  by  a  path  name  made  by  concatenating  all  the  element  names 
along  the  path. 

Another  CAI5  function  is  PKIMARY  NAME.  The  input  to  the  function  is  a  node  handle, 
and  the  function  returns  the  name  of  the  primary  path  to  the  node.  The  Priminaiy  Name  function 
returns  the  path  name.  For  example  the  path  from  node  Joe  to  node  Sam  is: 
'Cuirent_Nodc'Child(Sam).  Since  Currcnt^Node  is  the  default  relation,  the  path  can  also  be 
expressed  as:  'Child(Sam).  Child  is  the  name  of  a  relation.  Sam  is  a  particular  instance  of  the 
relation.  Since  Sam  is  the  only  instance,  the  relation  key  "Sam"  can  be  omitted  and  the  path 
expressed  as:  'Child .  The  relationship  DOT(A)  uses  the  default  relation  name  (DOT)  that  can  be 
expressed  in  two  ways,  Dot  or  (.).  Two  of  many  ways  of  expressing  the  path  between  the  current 
node  and  "A"  arc: 

’Child(Sam)'Dot(A)  or  ’Child(Sam)A 

It  is  dear  that  the  semantics  are  ambiguous.  There  are  many  different  strings  that  could  be 
returned  by  the  function.  If  the  intended  meaning  of  the  designers  was  that  any  valid  name  string  is 
acceptable,  this  could  be  stated  in  one  sentence.  However,  allowing  any  string  to  be  returned  may 
promote  implementations  that  hinder  transportability.  One  way  to  supplement  the  semantics  is  with 
the  following  paragraph: 

The  full  path  name  up  to  the  Currem_Node  shall  be  returned.  Relationship 
keys  shall  be  spelled  out  even  when  they  arelmique.  The  dot  relation  shall  be  in  the 
long  form. 

An  example  of  a  correct  name  using  the  network  of  Figure  3  is: 

•Child(Sam)'Dot(A) 
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4.3  Conclusion  on  Informal  Methods 

Using  English  narrative  and  examples  to  supplement  CAIS  semantics  has  strengths  and 
wcakensses.  Any  specific  ambiguity  in  the  CAIS  specification  can  be  corrected  by  t  combination  of 
narrative  and/or  examples  without  requiring  a  formal  description.  Examples  and  narrative  have  the 
advantage  of  being  easy  to  construct  and  comprehensible.  A  large  portion  of  CAIS  can  be  specified 
in  a  short  description.  The  short  description  provides  a  quick  introduction  to  which  details  can  be 
added.  The  primary  disadvantage  is  the  difficulty  in  obtaining  completeness  in  narrative 
specifications.  Narratives  cannot  be  used  for  formal  arguments  of  correctness  or  arguments  of 
interface  characteristics.  Descriptions  using  these  techniques  can  best  be  viewed  as  a  step  in  the 
process  of  developing  more  complete  and  formal  descriptions.  The  most  useful  form  of  narrative  is 
one  that  is  developed  in  conjunction  with  or  based  on  a  formal  description.  Doing  so  reduces  the 
tendency  toward  incompleteness  or  ambiguity. 

5.  ABSTRACT  MACHINE  DESCRIPTION 

A  report  from  a  preliminaiy  study  of  validation  in  an  APSE  [KAE-82]  indicates  that 
specifying  the  semantics  of  an  interface  such  as  CAIS  requires  more  than  a  description  of  the 
syntax  and  functionality  of  its  routines.  Interactions  that  exist  at  the  interface  must  be  specified. 
Interactions  may  include  routines  that  operate  on  a  common  data  structure,  routines  that  rely  on  data 
produced  by  a  tool  or  routines  depending  on  the  Ada  runtime  environment.  Furthermore,  any 
pragmatic  limits  which  apply  to  implementations  must  also  be  specified.  These  might  include  the 
length  of  identifier  strings,  field  sizes,  maximum  number  of  processes,  or  the  maximum  number  of 
times  that  an  interface  routine  may  be  called. 

Lindquist  [UN-84],  describes  an  Ada-based  Abstract  Machine  approach  to  describing  CAIS. 
Using  this  approach  functionality  is  operationally  described  in  the  form  of  Abstract  Machine 
Programs.  The  programs  are  written  in  Ada.  One  is  writ. ten  for  each  CAIS  routine  to  describe 
what  that  routine  docs.  If  there  existed  an  executor  for  the  programs  (the  Abstract  Machine)  then  an 
operational  definition  of  CAIS  would  exist.  In  late:  papers,  [LIN-85a,  SRI-85],  the  technique  is 
demonstrated  using  the  CAIS  process  model  and  applied  to  the  problem  of  generating  a  validation 
mechanism  for  CAIS  implementations.  As  depicted  in  Figure  4,  an  Abstract  Machine  consists  of 
three  components: 


1.  A  processor, 

2.  A  storage  facility,  and 

3.  An  instruction  set . 


Applvir.z  Semantic  Description  Techniques  to  Kernel  Facilities 


3-517 


The  processor  is  able  to  recognize  and  execute  instructions  from  a  predefined  set  Each 
instruction  has  an  action  that  the  processor  carries  out  in  some  data  contest  One  component  of  the 
processor,  called  the  environment  pointer,  indicates  the  dam  context  in  which  2n  instruction  is  to  be 
executed.  Another  component  called  the  instruction  pointer,  sequences  processor  execution 
through  the  instructions  of  the  program. 

The  storage  of  the  pi^cessor  is  memosy  for  both  daa  and  programs.  Data  storage  constitutes 
the  environment  used  by  the  processor  to  execute  instructions.  The  final  component  is  the 
instruction  s*.t 


Abstract  Machine 
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Figure  5.1.  CAIS  Abstract  Machine 
Figure  4.  CAIS  Abstract  Machine, 

Instructions  arc  taken  from  the  Ada  language  and  are  augmented  needed  primitive  operations. 
The  meanings  of  these  primitive  operations  are  left  to  the  description  of  the  Abstract  Machine. 
Additional  operations  can  be  viewed  as  extending  the  instruction  set  of  the  Abstract  Machine  to 
include  operations  beyond  the  scope  of  Ada. 

5.1  Ada  Abstract  Machines  to  Describe  CAIS 

Although  other  Abstract  Machines  could  be  used,  this  section  presents  one  that  is  Ada-based. 
Several  aspects  of  Ada  make  it  a  desirable  choice  for  this  description.  One  is  the  richness  of  the 
Ada  control  constructs  and  typing  facilities.  Further  support  for  using  Ada  lies  in  the  observation 
that  any  language  used  as  a  semantic  description  tool  must  have  a  well-defined  semantics  of  its 


Applying  Semantic  Description  Techniques  to  Kernel  Facilities 
3-518 


own.  Although  Ada  has  not  been  totally  specified  using  a  formal  technique,  the  language's 
controlled  definition  provides  an  adequate  basis  for  the  Abstract  Machine.  The  most  compelling 
reason  for  using  Ada  is  compatibility  with  the  uses  of  the  CAIS  specification.  CAIS  implementors 
and  users  are  familiar  with  Ada,  thus  making  an  Ada-based  Abstract  Machine  more  comprehensible 
and  useful. 

5.1.1  Node  Management  and  List  Utilities. 

CAIS  defines  a  set  of  list  manipulation  facilities  that  may  be  used  in  conjunction  with  the 
CAIS.  Lists  may  be  either  named  or  unnamed.  Named  lists  are  those  in  which  each  element  in  the 
list  has  a  unique  name.  The  package  includes  routines  for  constructing  generalized  lists  containing 
string,  interger,  list,  and  floating  point  elements.  Routines  to  add,  remove,  and  examine  elements 
of  a  list  are  provided.  An  Ada-based  Abstract  Machine  description  of  List  Utiulities  follows  the 
same  approach  as  an  Ada  implementation.  Figure  5  demons tratres  the  linking  structure  our 
definition  uses  for  the  example  named  list: 

(APPLE  m>  "GREEN”,  GRAPE  =>  (RED  =>  "SEEDLESS")) 

List  manipulation  routines  are  constructed  in  Ada  using  this  representation.  A  criticism  of 
Abstract  Machine  descriptions  is  that  the  code  itself  specifies  an  implementation  technique. 
Independent  of  the  machinery  selected,  instructions  to  cany-out  an  operation  must  indicate  an 
implementation  technique.  The  meanings  of  the  routines  are  not,  however,  derived  from  the  code, 
but  .instead  by  the  effect  of  executing  the  code  on  the  Abstract  Machine. 
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"SEEDLESS” 


Figure  5.  A  sample  list  implementation. 

The  CAIS  Node  Management  package  includes  facilities  for  manipulating  nodes,  which 
represent  entities  of  the  CATS  environment  Nodes  may  exist  for  processes,  files,  devices,  queues, 
and  node  structures.  Nodes  may  be  related  to  one  another  using  either  restricted  or  unrestricted 
relationships.  The  restricted  form  of  relationships,  called  primary  relationships,  require  that  each 
node  have  exactly  one  parent  (except  a  single  root  node).  The  unrestricted  form  allows  more 
general  (cyclic)  relationships  to  exist  among  nodes.  CAIS  Node  Management  provides  routines  for 
manipulating  nodes,  relationships  among  nodes,  and  attributes  (either  node  or  relationship 
attributes).  Node  Management  also  includes  access  mechanisms,  which  control  the  operations  that 
a  process  may  perform  on  a  node. 

The  Abstract  Machine  description  of  Node  Management  relies  heavily  on  data  mechanisms  of 
Ada.  Included  in  the  descripdon  are  substantial  uses  of  dynamic  structures  to  represent  nodes,  to 
store  relationships  between  nodes,  and  to  store  lists  and  attributes.  Access  types,  constrained 
record  types  and  exception  handling  mechanisms  arc  all  used  in  the  description. 

Exception  handling  facilities  are  used  throughout  the  CAIS  to  return  status  information  to  the 
tool  calling  CAIS.  Using  Ada  exception  mechanisms  in  the  Abstract  Machine  provides  an  excellent 
definition  of  status  returns  for  CAIS.  With  any  other  formal  semantic  description  (axiomatic  or 
denotations])  a  reasonable  overhead  equal  to  describing  Ada  language  exceptions  is  incurred. 

One  use  of  Ada  exceptions  within  Abstract  Machines  illustrates  the  problem  of  over 
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specifying  semantics.  For  instance,  suppose  the  CAIS  specification  indicates  an  incomplete  order 
for  generating  status  exceptions  to  allow  for  flexible  implementations.  Thus,  when  a  CAIS  routine 
is  called  with  arguments  that  would  produce  multiple  status  exceptions,  the  specification  does  not 
impose  a  complete  order  for  checking.  An  Abstract  Machine  description  does,  however,  fully 
specify  the  order  of  status  checking. 

5.1.2  Process  Control. 

The  Process  Control  section  of  CAIS  provides  routines  to  create  and  manage  the  execution  of 
Ada  programs.  Facilities  are  included  for  different  forms  of  invoking  processes,  awaiting 
completion,  and  manipulating  built-in  process  attributes. 

The  Abstract  Machine  description  relies  on  Ada's  tasking  facilities  to  describe  asynchronous 
processes  in  the  CAIS  environment  For  example,  in  the  Abstract  Machine  description  [SRI-85],  a 
process  node  is  represented  as  a  dynamically  created  (allocated)  record  object  Components  of  the 
object  contain  instances  of  task  types  which  provide  the  parallelism  and  synchronization  needed  for 
spawing  and  awaiting  processes.  A  user’s  process  structure  is  built  dynamically  and  is  a  tree  of 
tasks.  Each  process  includes  tasks  for  synchronization  and  for  representing  the  Ada  program.  An 
example  of  two  CAIS  processes  is  shown  in  Figure  6.  Process_node_l  has  spawned 
Proeess_node_2,  and  the  spawnedjprocess  task  is  used  to  synchronize  among  processes. 
Again,  the  use  of  Ada’s  tasking  facilities  in  the  Abstract  Machine  description  alleviate  the  need  to 
formally  redefine  asynchronous  facilities  in  some  other  descriptive  technique.  Both  axiomatic  and 
dcnotational  approaches  have  a  cumbersome  time  accommodating  concurrency.  Tasking  is  well 
understood  by  the  users  of  a  CAIS  specification,  which  eases  comprehension.  However,  we  note 
that  a  formal  specification  of  Ada  tasking  docs  not  yet  exist. 
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spawned— process 


LLL.  InauLamL-QiittmL 

Routines  for  manipulating  file  nodes  of  various  types  are  included  in  the  Input/Output  section 
of  CAIS.  Further  support  is  provided  for  common  types  of  terminals  and  magnetic  tapes.  To 
construct  an  Abstract  Machine  description  of  this  section  of  CAIS,  the  Abstract  Program  must 
create  software  devices  that  appear  to  the  CAIS  just  as  actual  devices  would  appear.  While  it  is 
possible  to  define  a  majority  of  the  input/output  facilities  using  an  Ada-based  Abstract  Machine, 
some  routines  do  not  lend  to  formal  specifications  using  any  technique.  Facilities  to  require  the 
operator  to  physically  mount  or  dismount  tapes  from  a  drive  exemplify  those  difficult  to  define 
formally.  Although  one  could  formally  define  routines  requesting  these  services,  the  need  to 
formally  define  such  facilities  can  be  argued. 
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S3  ANALYSIS  OF  ABSTRACT  MACHINES 

An  Ada-based  Abstract  Machine  description  of  CAIS  provides  some  distinct  advantages  in 
the  progression  to  a  mors  formal  specification  of  CAIS.  Some  of  theses  advantages  would  be  lost 
if  the  Abstract  Machine  description  were  to  be  formulated  in  a  language  other  than  Ada.  For 
example,  an  Ada-based  description  can  be  constructed  quickly.  If  another  language  were  used, 
then  the  problems  of  translating  the  meanings  of  asynchronous  activity  and  exception  handling  into 
the  notation  of  that  language  would  need  to  be  overcome.  Additionally,  an  Abstract  Machine 
description  in  another  language  would  not  be  as  comprehensible  to  the  Ada  conunmunity  as  is  a 
specification  in  Ada.  To  be  a  complete  formal  specification  of  CAIS,  an  Ada-based  Abstract 
Machine  description  must  be  accompanied  by  an  appropriate  formal  specification  of  the  machine 
instruction  set.  Inventing  and  defining  appropriate  instructions  to  augment  Ada  could  be  dor.c  to 
deal  with  drawbacks  such  as  over  specification. 

6.  AXIOMATIC  DESCRIPTION 

One  of  the  ubiquitous  comments  received  from  die  public  review  of  CAIS  1.1  is  the  need  for 
a  semantics.  There  are  a  variety  of  methods  for  presenting  a  formal  semantics,  and  this  section 
treats  the  axiomatic  approach.  There  is  no  escaping  the  fact  that  some  degree  of  mathematical 
maturity  is  required  to  comprehend  any  formal  semantics.  It  is  our  feeling,  however,  that  axiomatic 
semantics  is  the  most  comprehensible  to  the  largest  set  of  serious  CAIS  readers. 

Axiomatics  was  first  presented  by  Hoars  [HO A- 69],  and  has  been  applied  to  various 
languages;  the  most  notable  of  which. is  PASCAL  [HOA-73].  London  [LON-78]  has  applied  the 
method  to  EUCLID,  which  is  especially  interesting  since  the  langauge  was  designed  with  the  goal 
of  simplifying  program  proofs.  A  large  portion  of  this  presentation  is  based  on  Yelowitz 
[YEL-84]. 

In  a  mathematical  sense,  a  theory  ts  defined  by  applying  the  Axiomatic  method  to  a 
programming  langauge.  The  theory  consists  of  a  language  for  expressing  theorems,  a  set  of 
axioms  and  rules  of  inference.  A  theorem  of  the  theory  is  a  program  together  with  its  input  and 
output  specifications.  Minimally,  it  is  required  that  all  theorems  of  the  system  be  programs  which 
match  their  specifications;  that  is,  the  system  must  be  sound.  Axioms  and  rules  of  inference  are 
defined  to  determine  whether  or  not  a  program  and  its  specifications  form  a  theorem.  If  a  program 
and  its  specifications  are  derivable  from  the  axioms  and  rules,  then  they  constitute  a  theorem. 

By  derivable,  we  mean  that  there  exists  a  proof  of  the  theorem  ir.  the  system.  A  proof  is  a 
sequence  of  statements  in  the  theory  that  begins  with  an  axiom  and  ends  with  the  theorem.  Each 
statement  in  the  sequence  is  either  an  axiom  or  it  is  a  statement  that  can  be  written  by  applying  a  rule 
of  inference  to  statements  proceeding  it  in  the  proof. 
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Syntactically,  the  theorems  of  the  system  take  the  form: 

h  P  {  S  }  Q. 

Where  S  is  a  statement  or  set  of  statements  of  the  programming  language  and  P  and  Q  are 
predicates  (assertions)  over  the  variables  used  in  S.  Our  statements  are  Ada  lan gauge  statements 
augmented  by  calls  to  CAIS  interfaces.  The  turnstile,  |~,  indicates  that  P{S}Q  is  a  theorem  of  the 
system.  Innxitively ,  P{Q}S  can  be  interpreted  to  m ean,  if  P  is  true  before  execution  of  S,  then  Q 
will  be  true  after  execution  provided  S  halts. 

An  axiomatic  semantic  description  of  CAIS  can  be  formulated  in  conjunction  with  that  of  die 
Ada  language.  Assuming  that  such  a  definition  of  the  language  already  exists,  we  outline  here  how 
it  may  be  augmented  to  accommodate  CAIS.  CAIS  interfaces  may  be  treated  in  the  same  manner  as 
other  procedures  or  functions  invoked  by  an  Ada  program.  Input  and  output  predicates  may  be 
constructed  to  define  what  the  procedure  does.  The  free  variables  of  the  predicates  are  the 
parameters  and  nonlocals  referenced  by  the  procedure.  A  rule  for  the  CALL  statement  defines  how 
the  input  and  output  assertions  are  used  to  prove  procedure  calls.  Although  input  and  output 
assertions  could  be  defined  in  this  manner,  we  choose  to  represent  the  meaning  of  CAIS  facilities 
with  Axioms  (schemes)  to  more  accurately  reflect  the  relationship  between  CAIS  facilities  and  the 

language,  . 

We  now  present  the  background  needed  for  the  Axiom  scheme  for  the  Node  Model  routine 
COFYJNODE.  To  do  so  requires  formalization  of  notions  such  as  types  of  nodes,  contents  of 
nodes,  attributes  of  nodes,  and  relationships  among  nodes. 

6.1  The  CAIS  Node  Environment 

The  node  environment  can  be  described  as  a  directed  graph  in  which  arcs  are  labeled  and  may 
possess  attributes.  We  define  NODES  to  be  the  set  of  nodes  in  an  APSE. 

The  set  ARCS  includes  all  directed  edges  in  the  graph.  Thus: 

ARCS  e  NODES  X  NODES 

If  the  pair  (nj.nj)  e  ARCS  then  there  is  a  directed  edge  from  n^  to  We  refer  to  an 
element  of  ARCS  with  the  shorthand  aj  Labels  formalize  the  relationships  that  ARCS  represent. 
LABELS  is  a  set  of  the 

(relarion_name,  relations  hip_key) 

pairs  associated  with  each  arc  in  CAIS.  The  function  LABEL  names  each  arc  with  the 
appropriate  pair  as: 

LABEL  :  ARCS  ->  LABELS 

A  pathname  is  a  sequence  of  labels.  Thus  all  valid  pathnames  are  in  the  Kleene  star  of 
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LABELS  (LABELS*). 

OUT  ARCS  is  a  function  providing  for  each  node,  a  set  of  all  arcs  emanating  from  the  node. 

OUTARCS  :  NODES  ->  2ARCS 

That  is,  an  edge  is  in  the  set  of  out  arcs  of  a  node,  a,  when  it  emanates  from  n. 

a  £  OUTARCS(n)  iff  3  n1  e  NODES  and  a  -  (n,  np  £  ARCS 

Similarily  we  define  INARCS  to  be  the  set  of  all  edges  emanating  to  a  node. 

IN  ARCS:  NODE  -> 

The  predicate  ISPRIMARY  partitions  the  set  of  arcs  into  primary  and  secondary 
relationships.  CAIS  requires  that  all  primary  relationships  maintain  the  hierarchical  structure  of 
nodes.  We  describe  this  requirement  using  the  following: 

ISPRIMARY  :  ARCS  ->  {true,  false} 

Any  node  (except  the  systemroot)  must  have  exactly  one  primary  relationship  emanating  to  it.  This 
CAIS  requirement  can  be  expressed  as: 

V  n  e  NODES|  n  *  SYSTEMROOT  and  V  a,b  £  INARC(n) 

SINK(a)  -  SINK(b)  —>  not  ISPRIMARY  (a)  or  not  ISPRIMARY  (b) 

Where  SINK  is  the  node  an  are  emanates  to:  SINK:  ARC  — >  NODE 

CAIS  specifies  that  distinct  arcs  emanating  from  a  node  must  have  distinct  labels.  To 
describe  this  property,  we  have  the  following  predicate: 

V  n  £  NODES,  V  a^2  eARCS 

aj,a2  £  OUTARCS(n)  and  a^*a2  »■>  LABEL(ap  *  LABEL(a2) 

For  notational  convenience,  we  define  the  following: 

V  (x,y)E  ARCS,  Re  LABELS 

P(xtiLy)  denotes  ISPRIMARY((x,y))  and  LABEL((x,y)) «  R 
P(xjl,y)  means  there  is  a  primary  relationship  from  x  to  y  labeled  R,  and 

S(x,R,y)  denotes  not  ISPRIMARY((x,y))  and  LABEL((x,y))  ■  R 
S(xJLy)  means  there  is  a  secondary  relationship  form  x  to  y  labeled  R. 
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There  is  a  partitioning  of  the  set  of  nodes  into  four  disjoint  subsets: 

PROCES  S_N  ODES , 

STRUCTURAL_NODES, 

FUE_NODES, 

DEVICE_N  ODES ,  and 
QUEUE_N  ODES . 

These  subsets,  which  represent  the  different  types  of  CAIS  nodes,  allow  the  axiomatic 
descripdor.  to  distinguish  characteristics  particular  to  different  ypes. 

6.2  SEMANTICS  OF  COPY  NODE 


This  interface  is  used  to  make  a  copy  of  a  file  or  structural  node  having  no  primary 
relationships  emanating  from  it.  Secondary  relationships  emanating  from  the  node  are  copied,  as 
appropriate.  The  syntax  of  one  overload,  of  the  routine  is: 

procedure  COPY  NODE  (FROM,TO  BASE:  in  NODE  TYPE; 

TO  KEY:  in  RELATIONSHIP  KEY; 

to  “Relation  in  relation  Name  > 
DSPAULT_RELATION); 

Our  goal  is  a  predicate  transformer  for  each  interface  of  the  CAIS.  Since  the  transformers 
can  be  quite  extensive,  we  present  one  by  its  parts.  A  shorthand  notation  is  also  used  to  avoid 
complexity.  The  predicate  transformer  for  a  NAME_ERROR  is: 

(NOT  (RLN.KEY)  £  LABELS)  or 


(3  n  e  NODES  |  (BASEm)  e  ARCS  and  LABEL((BASE,n))  -  (RLNJKEY)) 


/  rnpv  >innF  (  FP^**  I*  a  ct:  nrv  dt  \r>  \ 
\  LUI  1  V.  1  AWw  A  f  /  J 


NAME  ERROR 


The  meaning  of  this  transformer  is:  if  prior  to  executing  the  call  to  COPY_NODE  the 
relation  name,  relationship  key  pair  are  either  illegal  or  the  nods  to  be  created  already  exists  then,  if 
execution  of  COPYJNODE  completes,  the  predicate  NAMEJERROR  will  be  satisfied.  To  simplify 
and  continue  the  example,  we  present  an  abbreviated  form  of  the  transformers  for  USE_ERROR, 
STATU S JERROR  and  the  functionality  of  COPY_NODE 

USEJERROR  is  generated  according  to  the  following  predicares.  Fast,  USE_ERROR  is 
raised  when  there  is  a  primary  arc  emanating  from  the  source  of  copying. 


3  n  e  NODES  |  (FROM,  n)  e  ARCS  and  PRIMARY ((FROMm)) 
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Next,  when  the  node  to  be  copied  (FROM)  isn't  either  a  FILE_NODE,  or  a 
STRU  CTURAL_N ODE ,  USE_ERROR  is  generated; 


not  FROM  eFILE_NODES  and  not  FROM  e  STRUCTURALNODES 

The  status  of  a  node  is  defined  by  the  function  N ODE_STATU S  as: 

NODE_STATUS  :  NODES  (OPENED,  CLOSED,  UNOBTAINABLE, 

NONEXISTENT} 

With  this  we  can  define  the  predicate  transformer  producing  a  STAUS  JERROR  as: 

NODEJTATUS  (FROM>OPENED  or  NODE_STATUS(BASE>OPENED 

Normal  Action.  With  these  definitions  for  exceptional  conditions,  we  can  define  the 
predicate  transformer  for  a  call  to  COPY_NODE  in  which  copying  takes  place.  The  exceptional 
status  conditions  given  above  can  all  be  placed  into  a  single  predicate  transformer.  To  do  so,  the 
precondition  for  each  precludes  the  others,  as  docs  the  corresponding  postcondition.  Each  unit  of 
the  predicate  transformer  corresponds  to  a  separate  action.  Below  is  the  transformer  describing 
normal  operation  of  COPY^NODE.  The  precondition  is  abbreviated  as  not 
STATUSJF.XCEPTION  to  indicate  that  no  status  returns  occur.  In  that  instance,  and  only  in 
that  instance,  the  copying  takes  place. 

not  STATUS_EXCEPTION  {COPY_NQDE(FROM,  BASE,  RLN,  KEY)} 

3  n  e  NODES  1  (BASE,  N)e  ARCS  and  P(BASE,(RINJ,KEY),n) 
and  LABEL((BASE^))-(RLN,KEY)  (0) 

and  CONTENTS(n)  -  CONTENTS  (FROM)  (1) 
and  (ATTRIBUTES(n) »  ATTRBUTES(FROM)  (2) 
and  KIND(n) «  KIND  (FROM)  (3) 

and  3  a  e  ARCS  1  a-(nBASE)  and  LABELS  a) «  (PARENT) 
and  S(n,(PARENT)3ASE  (4) 

and  V  a  e  ARCS  |  a-(FROM,  FROM)  3bEARCSl 
b«(nn)  and  LABEL(a)«LABEL(b)  (5) 

and  V  a  e  ARCS !  aK^OMEROM)  and  LAB  EL(a}*(P  AREN'T) 

2  b  E  ARCS  |  b«(n,SINK(a))  and  LABEL(b)-LABEL<a)  (6) 

The  postcondition  for  normal  operation  is  lengthy,  so  its  components  are  explained  by  line 
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number,  line  (0)  indicates  that  a  new  node,  n,  has  been  created  with  a  primary  relationship 
emanating  from  BASE  to  the  node.  The  relation  and  key  are  as  specified  through  arguments. 
Note,  however,  that  the  CATS  indicates  that  the  key  may  not  be  the  argument.  If  a  '#'  appears  as 
the  key  or  appended  to  the  key,  then  CAIS  returns  a  unique  key.  This  could  be  expressed 
axiomatic  ally  by  adding  additional  conjunct*  to  both  the  pie  and  post  assertions. 

Lines  (1),  (2),  and  (3)  indicate  that  the  contents,  attributes,  and  kind  of  the  copied  node 
match  the  original.  Lines  (4),  (5),  and  (6)  describe  the  newly  created  relationships  emanating  from 
the  copy.  Line  (4)  indicates  that  the  secondary  relationship,  parent,  for  the  copied  node  is  set  to 
BASE.  CATS  indicates  that  any  secondary  relationships  that  emanate  from  the  node  to  be  copied 
must  exist  in  the  copied  node  as  relations  emanating  back  to  the  copied  node.  Line  (5)  defines  this 
situation.  Note  that  it  is  not  necessary  to  specify  only  secondary  relationships  in  the  predicate  since 
there  are  no  primary  relationships  emanating  from  a  node  to  itself.  Line  (6)  indicates  that  there 
exists  a  secondary  relationship  in  the  copied  node  for  all  others  of  the  from  node  .  Thus,  for  all  arcs 
from  FROM,  which  don't  point  to  FROM  and  which  aren’t  parent  relationships,  there  is  a 
corresponding  are  from  the  copied  node  with  the  same  destination  and  label. 

6.3  Analysis  of  Axiomatic  Semantics 

Axiomatic  descriptions  that  rely  on  first  order  predicate  calculus,  which  we.  have  assumed 
here,  can  be  characterized  as  removing  all  temporal  information  from  the  description.  Having  no 
order  .pecified  alleviates  the  problem  of  over  specification  that  was  found  with  Abstract  Machines. 
Since  time  is  not  specified,  one  is  tempted  to  state  that  some  forms  of  status  returns  from  kernel 
interfaces  can’t  be  specified.  For  instance,  suppose  the  kernel  indicates  that  "when  conditions  for 
status  A  and  sums  B  are  both  satisfied,  that  A  Is  to  be  signaled”.  This  can,  however,  be  described 
axiomatically  with  predicates  indicating  that  5  is  raised  only  when  the  conditions  causing  it  exist 
and  those  causing  A  don't. 

There  are,  however,  two  problems  arising  from  the  lack  of  temporal  information.  First, 
aliases  may  exist  In  CAIS,  two  names  within  a  CAIS  implementation  may  refer  to  the  same 
object  For  example,  suppose  a  single  object  is  used  as  the  argument  to  two  or  more  in/out 
parameters  for  an  interface.  To  answer  the  question:  which  value  produced  for  the  parameters  will 
be  given  to  the  argument,  requires  temporal  information  about  the  implementation.  Second, 
asynchronous  and  parallel  computations  require  greater  descriptive  capability.  The  inability  to 
specify  time  dependencies  also  implicates  the  inability  to  specify  time  independencies.  The  CAIS 
process  model  provides  interfaces  for  concurrently  executing  processes,  as  well  as  for 
communication  and  synchronization  among  processes. 
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Exception  handling  causes  no  problem  to  axiomatic  descriptions  providing  that  the  routine 
signaling  the  exception  also  handles  it  In  the  CA1S  this  is  rarely  the  situation.  Exceptions  arc  used 
to  return  status  information.  Although  an  axiomatic  description  can  be  generated  to  indicate  that  a 
sums  exception  has  been  raised,  the  action  performed  to  handle  the  exception  is  cumbersome  to 
describe.  Thus  although  we  can  describe  the  CAIS,  we  can't  describe  the  meaning  of  a  program 
that  uses  CAIS  facilities.  Binding  a  raised  exception  to  a  handler  in  Ada  depends  on  the  execution 
flow  through  the  program.  The  procedure  call  history  is  needed  when  nested  procedure  calls  are 
made.  Ada's  rule  for  binding  exceptions  requires  that  the  exception  be  propagated  outward  to  all 
calling  procedures  until  one  containing  a  handler  is  found.  The  program  execution  path  needed  for 
this  binding  is  not  available  from  static  analysis. 

7.  DENOTATIONAL  DESCRIPTION 
7.1  Denotations!  Semantics:  Pragmatics 

The  dcnotational  approach  to  formal  semantics  involves  specifying  abstract 
mathematical  meanings  to  objects,  in  such  a  way  that  the  meanings  of  the  objects  are  modelled  by 
the  mathematical  abstractions.  The  mathematical  entities  that  are  used  for  this  purpose  (the 
denotations)  are  well-understood  classws  of  sets  and  functions.  The  denotational  approach  is 
suitable  for  modelling  machinr-indepcndent  meanings  because  of  its  emphasis  on  mathematical 
constructs.  Consequently,  the  denotational  approach  has  frequently  been  used  for  the  formal 
implementation-independent  specification  of  programming  languages,  and  for  deriving  rules  for 
proofs  of  program  properties  (an  axiomatic  semantics). 

The  essential  idea  in  a  denotational  semantics  is  to  map  the  syntactical  structures 
(some  sets  and  functions)  of  a  language  onto  some  semantic  structures  (other  sets  and  functions). 
This  is  done  so  that  every  legal  program  in  a  language  can  be  mapped  into  its  meaning.  The 
approach  usually  taken  is  to  recursively  describe  the  semantics  of  a  construct  in  terms  of  its 
sub-constructs.  The  use  of  the  denotational  approach  is  applicable  to  certain  types  of  sets,  called 
domains,  in  order  to  insure  convergence  in  the  recursive  application  of  functions.  The  formal 
mathematics  of  this  approach  was  presented  by  [Scott  and  Scrachey]. 

There  are  several  notations  (or  "meta-languages")  for  specifying  a  dcnotational 
semantics.  The  most  common  one,  used  by  [Tennent],  [Gordon]  and  [Stoy]  is  a  variant  of 
Lambda  Calculus.  This  notation,  while  mathematically  precise,  is  hard  to  read  by  many 
programmers  and  language  implementors.  Other  notations  that  have  also  been  proposed  include  the 
"Ada-Ukr."  notation  in  the  Ada  Formal  Semantic  Definition  [INRIA],  and  the  notations  developed  in 
the  Vienna  Definition  Method  [Bjoroer]. 
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Many  of  these  notations  have  automated  facilities  that  help  evaluate  and  sequence  a 
large  number  of  recursive  function  calls  that  stablish  the  meaning  of  a  construct  For  example, 
[Kini  et  al]  has  developed  tools  for  testing  the  denotanonal  semantic  definitions  of  prognmmong 
languages,  as  long  as  these  languages  are  defined  in  AFDL+  (an  extension  of  the  INRIA  notation). 
[Mossess]  has  also  developed  the  Semantics  Implementation  System  based  on  the  notation  in 
[Gordon].  These  systems  run  programs  that  "execute"  the  meta-language  equations  that  define  the 
semantics  of  a  construct.  In  one  sense,  development  of  these  tools  results  in  an  operational 
semantics  of  a  construct 

Denotational  semantics  have  been  used  to  formally  specify  programming  languages, 
compilers  [Gemmensen],  interpreters  [Stoy],  and  databases  [Bjorner].  There  is  also  a  formal 
specification  of  concurrency  presented  using  denotational  semantics  [Ginger],  Some  of  the  issues 
involved  with  specifying  kernel  facilities  based  on  the  denotational  approach  were  first  addressed  in 
[Freedman  1982]  and  [Freedman  1985].  In  the  following  sections,  we  show  what  is  entailed  to 
develop  a  denotanonal  semantics  for  kernel  interfaces. 

12  Denotational  Semantic  Domains 

The  denotanonal  semantics  of  a  kernel  interface  language  consists  of  the  semantics 
of  procedure  and  function  calls,  as  well  as  the  semantics  of  expression  evaluation.  In  order  to 
create  this  denotational  semantics,  we  need  to  specify  the  following' components: 

Syntactic  Domains 
Syntactic  Causes 
Semantic  Domains 
Semantic  Functions 
Semantic  Causes 

The  syntactic  domains  of  a  language  consists  of  different  syntactic  categories  that 
may  be  assigned  meaning.  These  categories  may  (recursively)  define  other  categories;  to  assure 
convergence,  domains  are  specified.  Some  examples  of  syntactic  domains  are  a  domain  of 
identifiers,  a  domain  of  commands,  and  a  domain  of  expressions.  For  CAIS  interfaces,  these 
domains  consist  of  identifiers,  expressions,  commands,  and  declarations. 

The  syntactic  clauses  show  how  a  syntactic  category  may  be  described  in  terms  of 
sub-categories.  For  example,  one  clause  may  specify  that  all  kernel  interface  commands  have  the 
form: 
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C  open(E)  |  close (E) 


where  E  is  in  the  domain  of  expressions.  The  notation  for  syntactic  clauses  usually  follows 
the  notation  for  specifying  the  concrete  syntax  (phrase  structure)  of  a  language.  However,  since 
only  the  meanings  of  constructs  and  sub-constructs  are  emphasised,  and  not  how  a  construct  is 
formed,  this  type  of  syntax  is  termed  the  abstract  syntax. 

The  semantic  domains  consist  of  well-understood  domains  that  are  either  given  (like 
the  domain  Bool «  {TRUE,,  FALSE} )  or  are  constructed  from  other  domains.  These  domains  arc 
the  actual  "denotations”  for  our  semantics.  The  most  important  of  these  domains  are  the 
Environment,  the  Store,  and  the  Continuation  domains.  For  example,  an  Environment  domain 
may  described  by  the  domain  of  functions  from  the  domain  of  identifiers  Ide  to  the  domain  or 
denotable  values  Dv,  or 

Env  ■  Ide  — >  Dv 

The  domain  of  denotable  values  must  be  defined  in  turns  of  other  domains:  the  denotable 
values  usually  contains  the  domain  of  locations.  The  Environment  is  changed  by  the  elaboration  of 
definitions.  Stores  may  be  described  by  the  domain  of  functions  from  the  domain  of  Locations  Loc 
to  the  domain  of  Storable  Values  5v,  or 

Stores  «  Loc  Sv 

Stores  are  changed  by  the  execution  of  comman&sThe  continuation  domains  may  be 
described  by  functions  from  "intermediate  results’’  to  '’final  results.”  Final  program  results  ate 
usually  expressed  in  terms  of  the  Store  domain.  For  example,  since  the  effect  of  executing  a 
command  is  to  change  the  Store,  the  domain  of  command  continuations  is  defined  by 

ComCont «  Store  — >  Store 

As  another  example,  since  the  effect  of  evaluating  expressions  is  a  value  and  a  store  (from 
possible  "side-effects"),  the  domain  of  expression  continuations  is 

ExpCont «  { Dv  x  Store]  Store 

The  above  expression  may  also  be  written  as 

ExpCont  *  [  Dv  ~>  Store  ]  ->  Store 

and  also  as 

ExpCont «  Dv  ->  StorC">  Store 

This  particular  form  of  function  notation  (the  "curried”  form)  is  what  makes  traditional 
denotational  semantics  difficult  to  read- 

Tbe  semantic  functions  are  functions  that  specify  the  denotation  of  the  syntactic 
domain  constructs  in  terms  of  the  semantic  domain  constructs.  For  example,  the  semantic  function 
for  expressions  may  be 
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E:  Exp  — >  Em'  ->Store  — >  Dv 

This  expresses  the  fact  that  the  semantics  of  "evaluating  an  expression"  is  a  value  that 
depends  on  an  environment  and  a  store.  Semantic  functions  are  defined  for  all  syntactic  domains. 

The  actual  semantics  for  the  constructs  that  range  over  ail  syntactic  domains  are 
defined  by  semantic  clauses.  A  semantic  clause  is  a  semantic  function  definition  for  a  particular 
syntactic  construct.  In  one  sertsu,  the  semantic  funcions  form  specifications,  while  the  semantic 
clauses  actually  "implement"  the  semantics.  For  example,  the  evaluation  of  the  expression  "1-1” 
denotes  TRUE,  given  an  arbitrary  store  s,  and  an  arbitrary  environment  m 
E  [  1-1]  n  s  -  TRUE 

Semantic  functions  traditionally  utilize  square  brackets  around  syntactic  constructs  to  increase 
readability.  Other  notation  for  semantic  clauses  may  correspond  to  more  familiar  programming 
language  syntax.  For  example,  in  the  AFDL  pNRIA]  "Ada-like”  notation,  the  semantic  function 
E  for  expressions  may  be  represented  as 

function  EVALJEXPRESSION  (  T:  SyntaxJTree;  En;  Environment;  S:  Store) 
return  Denctable JValues; 

The  semantic  clauses  for  all  expressions  would  correspond  to  the  function  bodies  of 
EVALJEXPRESSION,  for  all  possible  elements  of  SyntaxJTree.  The  disadvantage  of  this 
notation  is  its  ioeeonomy:  other  functions  (and  the  non- Ada  like  "function  type”)  must  be  defined 
to  achieve  all  meanings  of  the  functional  notation  form  for  E.  For  example,  E  [  open  (E1,I2J3,E4) 

]  u  is  a  function,  not  a  value. 

7.2.1  An  example  of  Denotational  Semantics  for  the  Specification  of  Kernel 

Interfaces 

Wc  provide  an  example  of  the  denotational  approach  to  describe  the  kernel  interfaces 
of  CAlS  package  Node_Managemcnt.  This  example  shows  the  beginning  specification  that  must 
be  specified  for  a  denotational  semantics:  the  domains  Node  and  Asv,  as  weii  as  most  semantic 
clauses  arc  left  incomplete. 

Kernel  Facility;  package  Nodc_Managemcnt 

Syntactic  Domains 

Ide  The  domain  of  identifiers  with  elements  I1J2,  ™ 

Exp  The  domain  of  expressions  with  elements  El,  E2,... 

Com  The  domain  of  commands  with  elements  Cl,  C2,... 

Dec  The  domain  of  declarations  with  elements  D1JD2,... 
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Syntactic  Clauses 

C  open  <H1^U3*H4); 

|  close  (11,1243,14); 

|  change  Jntent  (13  4233); 

I  copyjiode(I1424344); 

|  copyjree  (11424344); 

|  rename  (11424334); 

|  link  (El 32); 

|  iterate  ai 4243343536); 

|  get_next  (1142); 

|  setjcurentjjode  (E132); 

|  get_aurent_node  (II); 

E  is_open  (II) 

|  kind  (II) 

|  primary jiame  (II) 

I  primary  _kcy  (II) 

|  primary jnelaiion  (II) 

|  path_key  (II) 
i  pathjrc-larion  (11) 

1  obtainable  (II,  12,  E3) 

I  more  (El) 

|  is_same  (El  32) 

D  Ii:  nodejterator ; 

|  II:  relationship j£ey_pattern  >  El; 
|  II:  rdationjname_paitem  :■  El; 


Semantic  Domains 

Env  The  domain  of  environments  with  elements  u: 

Env  » Ide  ->  [Dv  +  {unbound}] 

Dv  The  domain  of  denotable  values  with  elements  ± 
Dv  ■  Loc  +  Asv  +  Cc  (Exceptions  are  dcnotable.) 
Lee  The  domain  of  locations  with  elements  L 
Asv  The  domain  of  assignable  values  with  elements  a. 
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Store  The  domain  of  stores  with  elements  s: 

Store  ■  Log  — a>  [Sv  +  {unused}] 

Sv  The  domain  of  storable  values  with  elements  v: 

Sv-Kode  + Asv 

Node  The  domain  of  nodes  with  elements  o. 

Cc  The  domain  of  command  continuations  with  elements  c: 

Cc  «  Store  ->  Store 

Ec  The  domain  of  expression  continuations  with  elements  Jc 

Ec  ■  Dv  ->  Cc 

Dc  The  domain  of  declaration  continuations  with  elements  d: 

Dc  ■  Env  — >  Cc 

Semantic  functions 

Semantics  of  expressions: 

E:  Exp  ->  Env  ->  Ec  ->  Cc 
Semantics  of  commands: 

C:  Com  — >  Env  — >Cc  — >Cc 
Semantics  of  declarations: 

Q:  Dec  ~>  Env ->  Dc ->  Cc 
Semantic  Clauses  (some  examples) 

Commands 

C  [  open  (E1J2J3E4)  ]  u  c  »  {meaning} 

Expressions 

E  [  is_opeu  (II)  ]  u  k  ■  {meaning} 

Declarations 

D  [  II:  nodsjterator  ]  u  d  ■  {meaning} 

7.3.  Analysis  of  Denotntional  Approach 

The  denotational  approach  to  formal  semantics  can  adequately  specify  kernel 
interfaces,  provided  one  interprets  these  interfaces  as  defining  a  language.  The  complete 
specification  of  CALS  semantics  for  storage  management  and  input/output  can  also  be  expressed, 
although  it  would  be  a  laboriov  *.  undertaking,  even  if  aided  by  automated  tools.  The  major  tasks  in 
these  areas  involves  selecting  a  formal  mathematical  model  for  the  CA1S  data  structures  and 
devices.  These  formal  models  would  then  be  represented  in  the  notation  chosen  for  the  domains. 
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Semantics  for  process  management  can  also  be  described  in  the  denotational  style,  assuming  that  a 
formal  model  of  concurrency  (like  Actor  Semantics)  is  also  similarly  selected. 

The  denotational  approach  is  not  an  alternative  method  to  specifying  semantics, 
rather,  it  emphasizes  a  different  perspective  toward  specification.  The  denotational  approach 
corresponds  to  a  "top-down"  solution  to  the  problem  of  defining  a  language:  the  emphasis  is  on 
developing  mathematical  domains  and  functions  to  model  machine  meanings  resulting  from 
program  execution.  The  operational  approach  corresponds  to  a  "bottom-up"  solution,  whereby  the 
emphasis  is  on  constructing  machine  operations  that  will  execute  programs.  An  algebraic 
semantics  is  also  a  denotational  semantics;  in  this  approach,  other  specific  mathematical  constructs 
are  used  (more  specific  then  domains)  for  representing  the  denotations.  As  observed  above,  a 
denotational  specification  becomes  an  operational  specification  if  tools  are  provided  that  can 
"execute"  the  denotational  semantic  notation.  Both  approaches  are  used  to  construct  rules  of 
program  properties  to  enable  an  axiomatic  semantics. 

It  is  not  clear  which  approach  is  best  for  the  specification  of  kernel  interfaces.  An 
operational  approach  would  probably  easier  to  understand  (but  harder  to  modify  or  check  for 
consistency  or  completeness)  then  a  denotational  sperrification;  conversely,  a  denotational 
specification  is  more  amenable  to  a  machine  independent  meaning.  This  lact  characteristic  is 
important  for  achieving  interoperability  and  transportability.  On  the  other  hand,  the  use  of 
denotational  semantics  for  the  specification  of  concurrent  computation  in  Ada  has  not  been  as 
adequately  addressed  as  in  some  other  languages;  this  implies  that  for  process  management,  at 
least,  many  researchers  are  more  comfortable  with  an  operational  approach. 


8.  CONCLUSIONS  AND  RECOMMENDATIONS 

We  have  described  how  several  semantic  description  techniques  would  be  applied  to  a  set  of 
kernel  facilities,  using  CAIS  as  an  example.  Considering  informal  methods,  such  as  English 
narrative  and  example  use,  we  have  shown  that  these  techniques  are  most  useful  during  the 
developmental  stage.  They  are  quickly  prepared  and  easily  comprehended,  which  are  important 
criteria  for  design  reviews.  The  techniques  lack  in  that  it  is  easy  to  prepare  descriptions  that  don't 
adequately  treat  details  and  are  ambiguous.  One  recommendation  is  to  explore  a  nanative 
description  that  is  developed  in  close  conj  motion  with  a  formal  description.  By  doing  so,  the 
resulting  description  would  be  precise  and  nearly  complete,  as  provided  by  the  use  of  a  formal 
definition  as  a  basis.  Further,  the  result  would  be  more  comprehensible  than  the  formal 
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Specification- 

Abstract  Machine,  Axiomatic  and  Denotational  descriptions  of  kernel  facilities  have  also  been 
studied.  These  techniques  have  all  been  found  to  contain  strengths  and  weaknesses  with  respect  to 
the  task  at  hand.  The  Abstract  Machine  description  we  presented,  while  comprehensible  to  the  Ada 
community,  lacks  in  applieabiliy  to  other  sets  of  interfaces.  Further,  the  reader  of  Abstract  Machine 
programs  is  tempted  to  infer  a  single  implementation  technique.  It  is  all  too  easy  to  adopt  the 
techniques  used  in  the  Abstract  Machine.  The  primary  advantages  of  the  Abstract  Machine 
descriptions  presented  are: 

1.  All  sections  of  the  CAIS  are  equally  well  described. 

This  is  an  attribute  that  is  not  shared  with  other  methods. 

2.  The  technique  lends  to  an  early  and  complete  operational 
definition. 

3.  Although  the  deseripdoa  is  not  formal,  it  defines  the  CAlS 
in  terms  of  the  Ada  langauge;  thus  centralizing  related 
products. 

An  axiomatic  description  of  the  node  management  facildy  COPY_NODE  is  presented  in  the 
paper  as  an  example.  It  demonstrates  an  application  amemable  to  axiomatic  description.  With  few 
exceptions,  an  axiomatic  description  of  the  Node  Management  section  of  CAIS  provides  a 
straightforward  semantics.  As  noted,  it  is  difficult  to  describe  exception  status  returns  and 
constructions  allowing  aliases  Axiomatically.  To  describe  the  process  control  facilities  of  CAIS, 
additional  formalism  is  needed.  Additionally,  an  axiomatic  description  of  input/outpuf  facilities 
would  be  bulky.  The  Axiomatic  method  does,  however,  lend  itself  to  proving  properties  of 
programs  using  CAIS  facilities. 

Adaptation  of  denotational  semantics  to  CAIS  is  also  straightforward  for  the  Node 
Management  facilities.  Existing  denotational  mechanisms  can  be  applied  directly  from  denotational 
descriptions  of  programming  langauges.  Again  with  this  approach,  input/output  and  process 
control  present  the  greatest  challenge  to  a  concise  denotational  description. 
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1.  Introduction. 


Software  Quality  Assurance  (SQA)  is  a  means  for  program  managers  to  ensure 
the  development  and  life-cycle  maintenance  of  high  quality  computer 
programs.  In  the  development  of  large  scale  computer  systems,  the.guarent.ee 
of  a  high  quality  software  systems  requires  a  continuance  of  comprehensive 
reviews.  These  reviews  ensure  well  defined  requirements,  specifications, 
design  3nd  code.  Upon  successful  completion  of  each  review  cycle,  the 
appropriate  products  are  baselined  and  identified  as  configuration  items 
(Cl).  The  CIs  are  placed  under  configuration  control  and  require  formal 
procedures  to  implement  any  changes.  The  purpose  of  strong  configuration 
control  is  to  further  ensure  that  the  quality  built  in  through  top-aown 
design  is  not  degraded  by  uncontrolled  changes.  SQA  can  be  visualized  as  a 
management  umbrella  under  which  the  activities  of  quality  control  (QC) , 
configuration  management  (CM)  and  evaluation  and  validation  (E&V)  are 
carried  out.  An  SQA  officer  can  act  as  the  program  manager's  coordinator 
who  maintains  a  system  perspective  of  the  entire  software  development  and 
establishes  a  system  of  independent  checks  and  balances  in  the  form  of 
reviews  and  audits  to  verify  the  quality  at  each  phase  of  development.  While 
it  is  recognized  that  excessive  SQA  activities  can  kill  any  project  by 
stifling  productivity;  too  little  SQA  can  allow  a  poor  or  unusable  program 
to  be  produced. 

Figure  1  illustates  the  documentation  scheme  currently  used  at  FCDSSA  San 
Diego.  This  is  based  on  using  MIL*STD-490  for  the  type  "A"  system 
specification  and  DOD-STD-1679  for  all  other  products.  The  documents  have 
been  divided  into  three  functional  areas  *  software  management,  software 
validation  (testing)  and  software  development.  The  series  of  reviews  and 
audits  as  well  as  the  configuration  status  accounting  are  the  activities 
and  reports  required  to  support  software  quality  assurance. 

Although  not  always  realized  by  the  software  engineers,  designers  and 
programmers,  implementation  of  management  disciplines  into  a  software 
project  are  as  important  as  the  engineering  disciplines.  Figure  2a  and  2b 
illustate  the  first  three  level  breakdown  for  a  software  project.  Figures  3 
and  4  expand  the  remaining  components  required  for  QC  and  CM  respectively. 

The  resources  to  support  software  engineering  and  management  varies  by 
project/program  and  depends  on  the  following  factors: 

a.  The  size  and  complexity  of  the  development  effort. 

b.  The  development  methodology  implemented. 

c.  The  anticipated  computer  program's  life-cycle. 

d.  The  extent  of  the  computer  program's  visibility  and  usage. 

e.  The  availability  of  applicable  automated  support  tools  or  systems. 

f.  The  requirements  and  constaints  directed  by  higher  authority. 

g.  The  budgetary  const3ints  imposed. 
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Figure  2a.  Software  Project  Component  Structure  (Engineering/Training) 
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2.  General  Concepts. 
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Guidelines  to  implement  quality  aoeuranee^into  any  software  development 
involves: 

a.  Integrating  the  software  engineering  and  software  management 
components  into  a  smooth  project  flow. 


b.  Prioritizing,  selecting  and  implementing  the  op 
into  the  project. 


opMmal  quaiAtyf  factors 


c.  Identifying  and  approving  all  applicable  standards,  guidelines  and 
criteria  before  their  required  implementation. 


d.  Providing  definitive  statements  of  work  (SOW)  for  all  development 
effort. 


e.  Providing  configuration  identification  for  all  products  slated  for 
configuration  control. 


f.  Providing  definitive  SOW's  for  all  formal  reviews  and  configuration 
audits  and  assigning  the  necessary  responsibility  and  authority.  ,  '  f/ 

g*y,T*«**> 

g.  Establishing  an  appropriate  baseline  concept  and  allocating  (ci)s  to 

each  baseline.  ^ 


h.  Establishing  or  identifying  a  suitable  configuration  status 
accounting  system, 

i.  Establishing  or  identifying  document  and  program  library  facilities 
and  assigning  each  Cl  to  the  appropriate  library. 

j.  Establishing  configuration  control  boards,  identifying  the  members 
and  defining  each  board  and  member's  duties. 

k.  Providing  for  periodic  monitoring  of  configuration  management  and 
testing  activities. 

l.  Providing  time,  personnel  and  funding  resources. 
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Figure  5.  Configuration  Management  Component  Structure 
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3.  Concepts. 

The  SQA  components  illustrated  in^  figure  3  provide  a  list  of  quaUAy  factors  ^ 

and  the  corresponding  e^SI^-yiactor  criteria.  The  concept  of  quullt>>  Jt**** 
factors  is  based  on  an  extensive  Air  Force  study;  the  reports  have  been 
republished  by  DOD.  Table  1  provides  definitions  for  quality  factors;  table 
2  provides  definitions  for  the  related  quality  factor  criteria.  While  there 
are  many  other  terms  to  describe  software  quality,  this  document  provides  a 
definitive  list.  Implementing  this  concept  allows  a  more  disciplined 
engineering  approach  to  software  quality  assurance.  The  software  program 
manager  is  provided  with  conceptually  simple,  easy  to  use  procedures  for 
specifying  required  quality  in  more  precise  terminology.  The  PM  essentially 
performs  a  trade-off  analysis  for  the  requirements  of  the  system.  The 
software  developer  is  forced  to  address  how  they  plan  to  build  the  required 
quality  into  the  software.  Specific  software  quality  attributes  required 
are  independent  of  the  design  and  implementation  techniques  used. 
Implementation  of  the  apolicable  quality  factors'  criteria  provides  the  PM 
with  a  quantifiable  criteria  against  which  to  judge  the  software  quality 
prior  to  acceptance  testing  and  operational  use. 

In  establishing  comprehensive  reviews  it  is  necessary  to  go  beyond  quality 
factors.  Reviews  must  also  include  operational  and  technical  evaluation  and 
the  conformance  to  applicable  standards.  While  it  usually  impossible  to 
find  a  single  person  capable  of  the  full  comprehensive  review  of  a  program, 
it.  is  possible  to  have  several  people  review  from  his  or  her  area  of 
expertise.  Thus  a  subjective  review  by  a  single  person  becomes  more 
objective  wnen  reviewed  by  several  people.  Further  refinement  is  possible  by 
implementing  checkoff  lists  for  each  product  being  reviewed  and  for  each 
applicable  criteria. 

Summary. 

Providing  quality  software  products  is  accomplished  by: 

a.  Developing  product  quality  through  definitive  statements  of  work. 

b.  Verifying  product  quality  through  comprehensive  reviews. 

c.  Validating  product  quality  through  thorough  testing. 

d.  Maintaining  product  quality  through  stringent  configuration  control. 
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FACTORS 


DEFINITIONS 


CORRECTNESS 

RELIABILITY 

EFFICIENCY 

INTEGRITY 

USABILITY 

MAINTAINABILITY 

FLEXIBILITY 

TESTABILITY 

PORTABILITY 

REUSABILITY 

INTEROPERABILITY 


Table  1 . 


Extent  to  which  a  program  satisfies  its 
specifications  and  fulfills  the  user's 
mission  objectives. 

Extent  to  which  a  program  can  be  expected  to 
perform  its  intended  function  with  required 
precisions.  ; 

The  amount  of  computing  resources  and  code 
required  by  a  program  to  perform  a  function. 

Extent  to  which  access  to  software  or  data 
by  unauthorized  persons  can  be  controlled. 

Effort  required  to  learn,  operate,  prepare 
input,  and  interpret  output  of  a  program. 

Effort  required  to  locate  and  fix  an  error 
in  an  operational  program. 

Effort  required  to  modify  an  operational 
program. 

Effort  required  to  test  a  program  to  ensure 
it  performs  its  intended  function. 

Effort  required  to  transfer  a  program  from 
one  hardware  configuration  and/or  software 
system  environment  to  another. 

Extent  to  which  a  program  can  be  used  in 
other  applications  -  related  to  the 
packaging  and  scope  of  the  functions  that 
programs  perform. 

Effort  required  to  couple  one  system  with 
another . 


Software  Quality  Factor  Definitions. 
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CRITERION 


DEFINITIONS 


TRACEABILITY 


COMPLETENESS 


CONSISTENCY 


ACCURACY 


ERROR  TOLERANCE 


feiMi'ljiwl-i  i 


MODULARITY 


Those  attributes  of  the  software  that 
provide  a  thread  from  the  requirements  t-to 
the  implementation  with  respect  to  the 
specific  development  and  operational 
environment. 


Those  attributes  of  the  software  that  pro¬ 
vide  full  implementation  of  the  functions 
reguired. 

Those  attributes  of  the  software  that 
provide  -uniform  design  and  implementation 
techniques  and  notation. 

Those  attributes  of  the  software  that 
provide  the  required  precision  in 
calculations  and  outputs. 

Those  attributes  of  the  software  that 
provide  continuity  of  operation  under 
adverse  operating  conditions. 

Those  attributes  of  the  software  that 
provide  implementation  of  functions  in  the 
most  understandable  manner.  (Usually 
avoidance  of  practices  which  increase 
complexity. } 

Those  attributes  of  the  software  that 
provide  a  structure  of  highly  independent 
modules . 


GENERALITY 


EXPANDABILITY 


INSTRUMENTATION 


SELF 

DESCKIPTIVENESS 


Those  attributes  of  the  software  that 
provide  breadth  to  the  functions  performed. 

Those  attributes  of  the  software  that 
provide  for  expansion  of  data  storage 
requirements  or  computational  functions. 

Those  attributes  of  the  software  that 
provide  for  the  measurement  of  usage  or 
identification  of  errors. 

Those  attributes  of  the  software  that  pro¬ 
vide  explanation  of  the  implementation  of  a 
function 


Table  2.  Criteria  Definitions  for  Software  Quality 


3-548 


CRITERION 


DEFINITIONS 


EXECUTION 

EFFICIENCY 


STORAGE 

EFFICIENCY 


ACCESS  CONTROL 


Those  attrributes  of  the  software  that  pro¬ 
vide  for  minimum  processing  time. 

Those  attributes  of  the  software  that  pro¬ 
vide  for  minimum  storage  requirements  during 
operation. 

Those  attributes  of  the  software  that  pro¬ 
vide  for  control  of  the  access  of  software 
and  data. 


ACCESS  AUDIT 


Those  attributes  of  the  software  that  pro¬ 
vide  for  an  audit  of  the  access  of  software 
and  data. 


OPERABILITY 


TRAINING 


Those  attributes  of  the  software  that  deter¬ 
mine  operation  and  procedures  concerned  with 
the  operation  of  the  software. 

Those  attributes  of  the  software  that  pro¬ 
vide  transition  from  current  operation  or 

1  — .  i  4.  /  -  1  £ - X  1  X  ~  2  ~  ^  ±  i 

iiu  tiai  i>cuuiiioiiibOVAMii* 


COMMUNICATIVENESS  I  Those  attributes  of  the  software  that  pro¬ 
vide  useful  inputs  and  outputs  which  can  be 
assimilated. 


SOFTWARE  SYSTEM 
INDEPENDENCE 


MACHINE 

INDEPENDENCE 


COMMUNICATIONS 

COMMONALITY 


DATA  COMMONALITY 


CONCISENESS 


Those  attributes  of  the  software  that  deter¬ 
mine  its  dependency  on  the  software  environ¬ 
ment  (operating  systems,  utilities,  input/ 
output  routines,  etc.) 

Those  attributes  of  the  software  that  deter¬ 
mine  its  dependency  on  the  hardware  system. 

Those  attributes  of  the  software  that  pro¬ 
vide  the  use  of  standard  protocols  and  in¬ 
terface  routines. 

Those  attributes  of  the  software  that  pro¬ 
vide  the  use  of  standard  data  representa¬ 
tions. 

Those  attributes  of  the  software  that  pro¬ 
vide  for  implementation  of  a  function  with  a 
minimum  amount  of  code. 


Table  2.  Criteria  Definitions  for  Software  Quality  (cont) 
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Ada  Interoperability  Survey 


The  Kernel  Ada  Programming  Support  Environment  (KAPSE)  Interface  Team 
(KIT)  /  KAPSE  Interface  Team  from  Industry  and  Academia  (kITIA)  would  like  to 
collect  data  about  the  Ada  Interooerabil Ity  problems  that  users  of  the  Ada 
language  and  Its  support  environments  are  experiencing.  The  attached  form  is 
provided  for  consistent  and  thorough  collection  of  relevant  data.  The  data 
collected  will  be  used  to  prepare  an  Ada  Interoperabil ity  Guide  which  will 
include  descriptions  of  actual  user  problems  as  well  as  proposed  solutions, 
work-arounds,  and  guidelines  for  promoting  the  interoperability  of  tools  and 
APSEs. 

The  following  examples  demonstrate  the  types  of  problems  KIT/KJTIA  is 
interested  in  documenting: 

a.  problems  associated  with  moving  data  across  APSEs, 

b.  problems  associated  with  rehosting  efforts, 

c.  incompatibilities  between  Ada  compilers  (e.g,,  creating  a 
data  file  with  a  program  generated  from  one  compiler  and  not 
being  able  to  read  the  data  with  a  program  generated  from  a 
different  compiler  on  the  same  machine), 

d.  incompatibilities  among  other  Ada  tools,  and 

e.  problems  that  may  occur  in  multi-lingual  environments  (e.g. 
translating  array  indexing  from  arrays  passed  between  Ada  and 
and  Fortran  procedures). 

Any  reports  of  Ada  interoperabil ity  problems  will  be  appreciated. 
KIT/KITIA  is  also  interested  in  related  interoperability  problems  that  do  not 
directly  involve  Ada. 

Please  send  the  completed  form  to  the  following  address: 

F.  Matthew  Emerson 
Naval  Avionics  Center,  D/825 
6000  E.  21st  Street 
Indianapolis,  IN  46219. 

A  copy  of  the  final  version  of  the  Ada  Interoperabi 1 ity  Guide  will  be 
mailed  to  the  mailing  address  provided  by  each  respondent  who  sends  us  at 
least  one  completed  Ada  Interoperability  Problem  Report  Form. 
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Ada  Interoperabil ity  Problem  Report  Form 


page  1  of  2 


1.  General  - - - - - 

1.1.  Organization: 

«> 

1.2.  Class  (General  Nature)  of  Problem  (one  word  or  phrase,  if  possible): 
-> 

1.3.  Oate  of  Problem: 

-> 

2.  Background - - - - - - - 

2.1.  Computer,  (berating  System,  and  APSE  (If  applicable): 

(include  version  numbers.) 

-> 

2.2.  Languages,  Tools,  and  Programs  Involved: 

(include  compilers  and  version  numbers.) 

-> 

2.3.  Project  Affiliation: 

_  *v 

3.  Communication - - - - 

3.1.  Name  of  Individual (s)  Involved: 

-> 

3.2.  Mail ing  Address: 

-> 

3.3.  Telephone  Number: 

-> 

3.4.  Net  Address: 

-> 
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page  2  of  2 


Interoperability  Problem  Report  Form 
4,  Detail . . . - . 

4.1.  Description  of  Problem: 

-> 


4.2.  Proposed  or  Working  (circle)  Solution: 
-> 
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Compiled  -  5/28/85 
Updated  -  8/12/85 

Updated  -  11/29/85 


DRAFT  KIT/K1T1A  GLOSSARY 

This  glossary  provides  definitions  for  the  terms  used  by  the 
KIT/K1TIA.  Most  terms  are  cited  in  the  three  KIT/KIT1A  documents 
listed  below.  Many  of  these  definitions  are  very  document-specific. 

1.  Proposed  MIL-STD-CAIS,  31  January  1985. 

2.  DoD  Requirements  and  Design  Criteria  for  the  Common  APSE  Interface 
Set  (CAIS),  13  September  1985.  (Better  known  as  the  RAC  document.) 

3.  Guidelines  and  Conventions  Working  Group  (GACWG)  Transportability 
Guide,  forthcoming. 

The  key  below  indicates  which  working  group  contributed  the  term. 


[C]  -  Term  is  defined  by  the  CAiSWG  and  is  cited  in  the  Proposed 
MIL-STD-CAIS  (Ref.  1  above). 

[CP]  -  Term  is  defined  by  the  COMPWG. 

[R]  -  Term  is  defined  by  the  RACWQ  and  is  cited  in  the  RAC  document  (Ref. 

2  above) . 

[G]  -  Term  is  defined  by  the  GACWG  and  is  cited  in  GACWG  Transportability 
Guide  (Ref  3  above) . 

No  letter(s)  and  no  brackets  indicates  that  the  word  is  a  general 
KIT/KIT1A  term. 


When  a  term  is  taken  from  another  source,  the  source  document  is 
abbreviated  within  parentheses  preceding  the  definition.  Following  the 
glossary  is  a  list  of  the  abbreviations  and  complete  titles  for  these 
references. 
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DEFINITION 


TERM 


abort  [C]  - 

(IEEE)  To  terminate  a  process  prior  to  completion. 

abstract  machine  [CP]  - 
TBD 

access  [C]  - 

(TCSEC)  A  specific  type  of  interaction  between  a  subject  and  an 
object  that  results  in  the  flow  of  Information  from  one  to  the  other. 

access  checking  [C]  - 

The  operation  of  checking  access  rights  against  those  rights  required 
for  the  intended  operation,  according  to  the  access  control  rules,  and 
either  permitting  or  denying  the  intended  operation. 

access  control  [C]  - 

(TCSEC)  (1)  discretionary  access  control:  A  means  of 
restricting  access  to  objects  based  on  the  identity  of 
subjects  and/or  groups  to  which  they  belong.  The  controls  are 
discretionary  in  the  sense  that  a  subject  with  a  certain 
access  permission  is  capable  of  passing  that  permission 
(perhaps  indirectly)  on  to  any  other  subject.  (2)  mandatory 
access  control:  A  means  of  restricting  access  to  objects  based 
on  the  sensitivity  (as  represented  by  a  label)  of  the 
information  contained  in  the  objects  and  the  formal 
authorization  (i.e.,  clearance)  of  subjects  to  access 
information  of  such  sensitivity.  In  the  CAIS,  this  includes 
specification  of  access  rights,  access  control  rules  and  checking 
of  access  rights  in  accordance  with  these  rules. 

access  control  constraints  [C]  - 

The  resulting  restrictions  placed  on  certain  kinds  of  operations 
access  control . 

access  control  information  [C]  - 

All  the  information  required  to  perform  access  checking. 

access  control  rules  [C]  - 

The  rules  describing  the  correlations  between  access  rights  and 
those  rights  required  for  an  Intended  operation. 

access  relationship  [C]  - 

A  relationship  of  the  predefined  relation  ACCESS. 

access  rights  [C]  - 

Descriptions  of  the  kinds  of  operations  which  can  be  performed, 
access  to  a  node  [C]  - 

Reading  or  writing  of  the  contents  of  the  node,  reading  or  writing  of 
attributes  of  the  node,  reading  or  writing  of  relationships  emanating 
from  a  node  or  of  their  attributes,  and  traversing  a  node  as  implied 
by  a  pathname. 


accessibility  [C]  - 

The  subject  has  (adopted  a  role  which  has)  been  granted  the  access  right 
EXISTENCE  to  the  object. 

activate  [R]  - 

To  create  a  CAIS  process.  The  activation  of  a  program  binds  that 
program  to  its  execution  environment,  which  are  the  resources  required 
to  support  the  process's  execution,  and  includes  the  program  to  be 
executed.  The  activation  of  a  process  marks  the  earliest  point  In  time 
which  that  process  can  be  referenced  as  an  entity  within  the  CAIS 
envi ronment. 

active  position  [C]  - 

The  position  at  which  a  terminal  operation  is  to  be  performed. 

Ada  Programing  Support  Environment  (APSE)  [C]  - 

(UK  Ada  Study,  STONEMAN)  A  set  of  hardware  and  software  facilities 
whose  purpose  is  to  support  the  development  and  maintenance  of  Ada 
applications  software  throughout  its  life-cycle  with  particular 
emphasis  on  software  for  embedded  computer  applications.  The  principal 
features  are  the  database,  the  interfaces  and  the  tool  set. 

adopt  a  role  [C]  - 

The  action  of  a  process  to  acquire  the  access  rights  which  have  been 
or  will  be  granted  by  an  object  to  adopters  of  that  role;  in  the  CAIS 
this  is  accomplished  by  establishing  a  secondary  relationship  of  the 
predefined  relation  AD0PT£D_R0LE  from  the  process  node  to  the  node 
representing  the  role. 

adopted  role  of  a  process  [C]  - 

The  access  rights  associated  with  the  node  that  is  the  target  of  a 
relationship  of  the  predefined  relation  AD0PTED_R0LE  emanating  from 
the  process  node  or  with  any  group  node  one  of  whose  permanent 
members  is  the  target  of  such  a  relationship. 

advance  (of  an  active  position)  [.Cj  - 

(1)  Scroll  or  page  terminal:  Occurs  whenever  (i)  the  row  number  of  a 
new  position  is  greater  than  the  old  or  (ii)  the  row  number  of  the  new 
position  is  the  same  and  the  column  number  of  the  new  position  is 
greater  than  that  of  the  old.  (2)  Form  terminal:  Occurs  whenever  the 
indices  of  its  position  are  incremented. 

approved  access  rights  [C]  - 

Access  rights  whose  names  appear  in  resulting  rights  lists  of  relevant 
grant  items  for  which  either  (i)  the  necessary  right  is  null  or  (ii) 
the  necessary  right  is  an  approved  access  right. 

archive  [R]  - 

A  subset  of  the  CAlS-managed  data  that  has  been  relegated  to  backing 
storage  media  while  retaining  the  integrity,  consistency  and 
availability  of  all  information  in  the  entity  management  system. 

area  qualifier  [C]  - 

A  designator  for  the  beginning  of  a  qualified  area. 


attribute  [C]  - 

A  named  value  associated  with  a  node  or  a  relationship  which  provides 
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Information  about  that  node  or  relationship. 


attribute  [R]  - 

An  association  of  an  entity  or  relationship  with  an  elementary  value, 
axiomatic  semantics  [CP]  - 

Axiomatic  semantics  of  the  CAIS  involves  stating  consistency  conditions 
of  states  of  the  CAIS  using  predicate  calculus  in  which  these 
consistency  conditions  must  hold  for  all  states.  Then,  the  effects 
of  subprogram  interfaces  of  the  CAIS  are  specified  using  the 
predicate  calculus  to  describe  state  changes  brought  about  by 
invoking  the  given  subprogram.  Finally,  it  Is  proven  that  the 
consistency  conditions  remain  invariant  after  Invocation  of  any 
subprogram. 

backup  [R]  - 

A  redundant  copy  of  some  subset  of  the  CAlS-managed  data.  The  subset 
is  capable  of  restoration  to  active  use  by  a  CAIS  Implementation, 
particularly  in  the  event  of  a  loss  of  completeness  or  integrity  in  the 
data  in  use  by  implementation, 

block  data  [R]  - 

A  sequence  of  one  or  more  data  units  which  is  treated  as  an  indivisible 
group  by  a  transmission  mechanism. 

block  terminal  [R]  - 

A  terminal  that  transmits/receives  a  block  of  data  units  at  a  time. 
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A  representation  of  a  value  of  an  Ada  discrete  type. 


closed  nodr  handle  [C] 

A  node  handle  which  is  not  associated  with  any  node. 


completion  [R]  - 

The  voluntary  termination  of  a  process.  Completion  of  a  process  is 
always  self-determined. 


consumer  [R]  - 

An  entity  that  is  receiving  data  units  via  a  datapath. 


contents  [C]  - 

A  file  or  process  associated  with  a  CAIS  node. 


couple  [C]  - 

To  establish  a  correlation  between  a  queue  file  and  a  secondary 
storage  file.  If  the  queue  file  is  a  copy  queue  file,  its  initial 
contents  is  a  copy  of  the  secondary  storage  file  to  which  it  is 
coupled;  if  the  queue  is  a  mimic  queue  file,  its  contents  is  a  copy  of 
the  secondary  storage  file  to  which  it  is  coupled,  and  elements  that 
are  written  to  the  mimic  queue  file  are  appended  to  its  coupled  file. 

current  job  [C]  - 

The  root  process  node  of  the  tree  containing  the  current  process  node; 
represented  by  the  predefined  relation  CURRENT_JOB. 

current  node  [C]  - 

The  node  that  is  currently  the  focus  or  context  for  the  activities  of 
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the  current  process;  represented  by  the  predefined  relation 
CURRENT  NODE, 


current  process  [C]  - 

The  currently  executing  process  making  the  call  to  a  CAIS  operation. 
Pathnames  are  interpreted  in  the  context  of  the  current  process. 

current  user  [C]  -  The  user's  top-level  node;  represented  by  the  secondary 
relationship  of  the  predefined  relation  CURRENTJJSER. 

data  unit  [R]  - 

A  representation  of  a  value  of  an  Ada  discrete  type, 
datapath  [R]  - 

The  mechanism  by  which  data  units  are  transmitted  from  a  producer  to  a 
consumer. 

datastream  [R]  - 

The  data  units  flowing  from  a  producer  to  a  consumer  (without  regard 
to  the  implementing  mechanism). 

deactivate  [R]  - 

To  remove  a  terminated  process  so  that  it  may  no  longer  be  referenced 
within  the  CAIS  environment. 


denotational  semantics  [CP]  - 
TBD 


descendant  (of  a  node)  [C]  - 

Any  node  which  is  reachable  from  other  nodes  via  primary  relationships. 

dependent  process  [C]  - 

A  process  other  than  a  root  process. 


device  [C]  - 

(WF.BS)  A  piece  of  equipment  or  a  mechanism  designed  to  serve  a 
special  purpose  or  perform  a  special  function. 
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The  keys  of  a  primary  relationship  of  the  predefined  relation  DEVICE. 

discretionary  access  control  [C]  - 
See  access  control . 


element  (of  a  file)  [C]  - 

A  value  of  the  generic  data  type  with  which  the  input  and  output 
package  was  instantiated;  see  [LRM]  for  additional  information. 

elementary  value  [R]  - 

One  of  two  kinds  of  representations  of  data:  interpreted  and 
uninterpreted. 

encapsulation  [G]  - 

Encapsul atvon  means  placing  procedures,  functions,  exceptions,  types, 
etc.  that  all  pertain  to  the  same  object  into  one  package. 

end  position  [C]  - 

The  position  of  a  form  identified  by  the  highest  row  and  column  indices 
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of  the  form. 


entity  [R]  - 

A  representation  of  a  person,  place,  event  or  thing, 
exact  identity  [R]  ~ 

A  designation  of  an  entity  (or  relationship)  that  is  always  associated 
with  the  entity  (or  relationship)  that  It  designates.  This  exact 
Identity  will  always  designate  exactly  the  same  entity  (or 
relationship),  and  it  cannot  be  changed. 

extensible  [R]  - 

Designed  to  facilitate  development  and  use  of  portable  extensions; 
reuseable  to  facilitate  combination  to  create  new  interfaces  and 
facilities  which  are  also  portable. 

external  file  [C]  - 

(LRM  14.1.1  -  Ada  external  file)  Values  input  from  the  external 
environment  of  the  program,  or  output  to  the  environment,  are 
considered  to  occupy  external  files.  An  external  file  can  be  anything 
external  to  the  program  that  can  produce  a  value  to  be  read  or 
receive  a  value  to  be  written. 

file  [C]  - 

See  external  file. 

file  handle  [C]  - 

An  object  of  type  FILE_TYPE  which  is  used  to  identify  an  internal  file, 
file  node  [Cj  - 

A  node  whose  contents  are  an  Ada  external  file,  e.g.,  a  host  system 
file,  a  device,  or  a  'queue. 

form  [C]  - 

A  form  is  a  two-dimensional  matrix  of  character  positions, 
group  [C]  - 

A  collection  of  nodes  representing  roles  and  identified  by  a  structural 
node  with  emanating  relationships  of  the  predefined  relations 
POTENTIAL^ MEMBER  and  PERMANENT__MEMBER  identifying  each  of  the  group's 
members .  A  member  may  be  a  useF  top-level  node;  a  node  representing 
the  executable  image  of  a  program,  or  a  node  representing  a  group. 

hardcopy  terminal  [R]  - 

A  terminal  which  transmits/receives  one  data  unit  at  a  time  and  does 
not  have  an  addressable  cursor. 

history  [R]  - 

A  recording  of  the  manner  in  which  entities,  relationships  ano 
attribute  values  were  produced  and  of  all  information  which  was 
relevant  in  the  production  of  those  entities,  relationships  or 
attribute  values. 


host  - 


(K/K)  A  host  is  a  computer  upon  which  an  APSE  resides,  executes  ana 
supports  Ada  software  development  and  maintenance.  Examples  are 
IBM  360/370,  VAX  11/760,  CDC  6000/7000,  DEC  20  and  UNIVAC  1110  with 
any  of  their  respective  operating  systems. 
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identification  [R]  - 

A  means  of  specifying  the  entities,  relationships  and  attributes  to 
be  operated  on  by  a  designated  operation. 

illegal  identification  [C]  - 

A  node  identification  in  which  the  pathname  or  the  relationship  key 
or  relation  name  is  syntactically  illegal  with  repect  to  the  syntax 
defined  in  Table  1  (of  proposed  MIL-STD-CA1S,  31  January  1985). 


inaccessible  [C]  - 

The  subject  has  not  (adopted  a  role  which  has)  been  granted  the  access 
right  of  EXISTENCE  to  the  object. 

initiate  [C]  - 

To  place  a  program  into  execution;  in  the  CAIS,  this  means  a  process 
ncde  is  created,  a  process  Is  created  as  its  contents,  required 
resources  are  allocated,  and  execution  is  started. 


initiated  process  [C]  - 

The  process  whose  program  has  been  placed  into  execution. 

initiating  process  [C]  - 

The  process  placing  a  program  into  execution. 


isolation  [G]  - 

Isolation  means  hiding  a  particular  implementation  in  the  package 
body.  Typically  Isolated  packages  do  not  depend  on  other  packages 
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interface  [C]  - 

(DACS)  A  shared  boundary. 

internal  file  [C]  - 

A  file  which  is  internal  to  a  CAIS  process.  Such  a  file  is  identified 
by  a  file  handle. 


interoperabil  ity  - 

( K/K )  Interoperability  is  the  ability  of  APSEs  to  exchange 
data  base  objects  and  their  relationships  in  forms  usable  by 
tools  and  user  programs  without  conversion.  Interoperability 
is  measured  in  the  degree  to  which  this  exchange  can  be 
accomplished  without  conversion. 

interpreted  data  [R]  - 

A  data  representation  whose  structure  is  controlled  by  CAIS  facilities 
and  may  be  used  in  the  CAIS  operations.  Examples  are  representations 
of  integer,  string,  real,  date  and  enumeration  data,  and  aggregates  of 
such  data. 


iterator  [C]  - 

A  variable  which  provioes  the  bookkeeping  information  necessary  for 
iteration  over  nodes  (a  node  iterator)  or  attributes  (ar  attribute 
Iterator) . 

job  [C]  - 

A  process  node  tree,  spanned  by  primary  relationships,  which  develops 
under  a  root  process  node  as  other( dependent)  processes  are  initiated 
for  the  user. 
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KAP5E  - 

( ijK  Ada  Study)  That  level  of  an  APSE  which  provides  database 
communication  and  runtime  support  functions  to  enable  the 
execution  of  an  Ada  o-ogiam  (Including  a  MAPSE  tool)  and  which 
presents  l  machine-:  pendent  portability  interface. 

key  [C]  - 

See  relationship  key.  The  key  of  a  node  is  the  relationship  key  of  the 
last  element  of  the  node's  pathname. 

label  group  (of  a  magnetic  tape)  [C]  - 

One  of  the  following:  (i)  a  volume  header  and  af  file  header  label, 

(ii)  a  file  header  label,  or  (iii)  and  end-of-file  label. 

latest  key  [C]  - 

The  final  pert  of  ?  key  that  is  automatically  assigned 
lexicographically  following  all  previous  keys  for  the  same  relation 
names  ana  initial  relationship  key  character  sequence  for  a  given  nooe. 


1 i st  [C]  - 

(IEEE)  An  ordered  set  of  items  of  d2ta;  in  the  CAIS,  an  entity  of 
LIST  TYPE  whose  value  is  a  linearly  ordered  set  of  data  elements. 


1 i st  i tern  [C j  - 

A  data  element  in  a  list. 


mandatory  access  control  [C] 
See  access  control . 


MAPSE  - 

(UK  Ada  Study,  STONEMAN)  That  level  of  an  APSE  which  provides 
a  minimal  set  of  tools,  written  in  Ada  and  supported  by  the 
KAPSE,  which  are  both  necessary  and  sufficient,  for  the 
development,  and  continuing  support  of  Ada  programs.  The  term 
is  used  in  this  [UK]  study  to  mean  not  a  strictly  minimal  set, 
but  a  set  with  which  a  user  can  happily  work. 

modular  [R]  - 

Designed  such  that  it  may  be  understood  in  isolation  and  such  that 
there  are  no  hidden  Interactions, 
named  item  [C,]  - 

A  list  item  which  has  name  associated  with  it. 
named  list  [C]  - 

A  list  whose  Hems  are  all  named. 


node  C-3  - 

A  representation  within  the  CAIS  of  an  entity  relevant  to  the 
Af’SL. 

node  handle  [C]  - 

An  Ada  objei  t  of  type  N0UI._TYPL  which  is  used  to  identify  a  CAIS  node; 
It  Is  mtcinal  to  a  process. 

r.on-cxi sting  nuic  [C]  - 

A  nodj  which  has  never  h*'en  created. 
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object  [C]  - 

(TCSEC)  A  passive  entity  thr.t  contains  or  receives  information.  In 
the  CAIS,  any  node  may  be  an  object. 

obtainable  [C]  - 

A  node  is  obtainable  if  it  is  created  and  not  deleted, 
open  node  handle  [C]  - 

A  node  handle  that  has  teen  assigned  to  a  particular  node. 

operational  semantics  [CP]  - 
T3D 

page  terminal  [R]  - 

A  terminal  which  transnits/r2ceives  one  data  urit  at  a  time  and  has 
an  addressable  cursor. 

parent  [C]  - 

The  source  node  of  a  primary  relationship;  also  the  target  of  a 
relationship  of  the  predefined  relation  PARENT. 

path  [C]  - 

A  sequence  of  relationships  connecting  one  node  to  another. 

Starting  from  a  given  node,  a  path  is  followed  by  traversing  a 
sequence  of  relationships  until  the  desired  node  is  reached. 

path  element  [C]  - 

A  portion  of  a  pathname  representing  the  traversal  of  a  single 
relationship;  a  single  relation  name  and  relationship  key  pair. 

pathname  [C]  - 

A  name  for  a  path  consisting  of  the  concatenation  of  the  names  of  the 
traversed  relationship  in  the  path  In  the  same  order  in  which  they 
are  traversed. 

permanent  member  [C]  - 

A  group  member  which  is  intrinsically  related  to  the  group  via 
primary  rg ! £ti onshi ps  of  the  predefined  relation  PERMANENT  MEMBER. 

position  (of  a  terminal)  [C]  - 

A  place  In  an  output  device  In  which  a  single,  printable  ASCII 
character  may  be  graphically  displayed. 

potential  member  [C]  - 

A  group  member  that  may  dynamically  acquire  membership  in  the  group; 
represented  by  a  node  that  Is  the  target  of  a  secondary  relationship 
of  the  predefined  relation  POTENTIAL  MEMBER  emanating  form  that  group 
node  or  form  any  of  that  group  nodes’1''  descendants. 

pragmatics  [C]  - 

Contralnts  Imposed  by  ai.  Implementation  that  arc  not  defined  ty  the 
syntax  or  semantics  of  tne  CAIS. 

primary  relationship  [C]  - 

The  Initial  relationship  established  from  an  existing  node  to  a  newly 
created  node  during  its  creation.  The  existence  of  a  node  Is 
determined  by  the  existence  of  the  primary  relationship  of  which  It  is 
the  target. 


s  *>ol 


process  [C]  - 

The  execution  of  an  Ada  program  including  all  its  tasks, 
process  [R]  - 

The  CA1S  facility  used  to  represent  the  execution  of  any  program, 
process  node  [C]  - 

A  node  whose  contents  represent  a  CA1S  process, 
producer  [R]  - 

An  entity  that  is  transmitting  data  units  via  a  datapath, 
program  [C]  - 

(LRM)  A  program  is  composed  of  a  number  of  compilation  units, 
one  of  which  is  a  subprogram  called  the  main  program. 

program  [R]  - 

A  set  of  compilation  units,  one  of  which  is  a  subprogram  called  the 
"main  program."  Execution  of  the  program  consists  of  execution  of 
the  main  program,  which  may  invoke  subprograms  declared  in  the 
compilation  units  of  the  program. 

qualified  area  [C]  - 

A  contiguous  group  of  positions  in  a  form  that  share  a  common  set 
of  characteristics. 


queue  £C] 


IEEE)  A  list  that  is  accessed  in  a  first-in,  first-out  manner. 


rehost ab 11 ity  - 

(K/K)  Rehostabil ity  of  an  ARSE  Is  the  ao-lity  of  the  APSE  to  be 
Installed  on  a  different.  HOST.  Rehostabil  ity  is  measured  In  the 
degree  to  which  the  install  at! or  can  be  accomplished  with  needed 
re- programming  localized  to  the  KAPSE,  Assessment  of  rehostabi h ty 
includes  any  needed  change:,  to  non-KAPSE  components  of  the  APSE, 

In  addition  to  the  changes  to  the  ><AP5E. 

relation  LC]  - 

In  the  node  model,  a  cltss  of  relationships  sharing  the  same  name, 
relation  name  [C]  - 

The  string  that  Identifies  c-  relation, 
relationship  [C]  - 

In  the  node  model,  an  edyv  of  the  directed  graph  which 
emanates  from  a  so:; roe  node  r. n<1  f.emiir.ati's  from  a  target  node. 

A  relationship  is  an  instance  of  a  relation. 

relationship  [R]  - 

An  ordered  connection  tir  ossocl  fltiori  among  entitles.  A  relationship 
among  h  entitles  (not  necessarily  distinct)  is  known  as  an 
"N-ary"  relationship. 

relfl' 1onsh1{  key  Itj  - 

The  string  that  distinguishes  a  relationship  fiom  other 
relationships  having  the  spine  relation  name  and  emanating  from  toe 
same  node . 
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relevant  grant  Items  [C]  - 

The  items  in  values  of  GRANT  attributes  of  relationships  of  the 
relation  ACCESS  emanating  from  the  object  and  pointing  at  any  node 
representing  a  role  which  is  an  adopted  role  of  the  subject  or 
representing  a  group,  one  of  whose  permanent  members  is  an  adopted 
role  of  the  subject. 

resource  [R]  - 

Any  capacity  which  must  be  scheduled,  assigned,  or  controlled  by  the 
operating  system  to  assure  consistent  and  non-conflicting  usage 
by  programs  under  execution.  Examples  of  resources  include:  CPU 
time,  memory  space  (actuals  and  virtual),  and  shared  facilities 
(variables,  devices,  spoolers,  etc.). 

resume  [R]  - 

To  resume  the  execution  of  a  suspended  process. 


retargetabl ity  - 

( K/K )  Retargetabil ity  is  the  ability  of  a  target-sensitive  APSE 
tool  to  accomplish  the  same  function  with  respect  to  another 
target.  Retargetabil ity  ir  measured  in  the  degree  to  which  this 
can  be  accomplished  without  modifying  th®  tool.  Not  all  tools  will 
have  target  specific  functions. 


reusability  - 

(K/K.)  Reusability  is  the  ability  of  a  program  unit  to  be  employed 
In  the  design,  documentation,  and  construct  on  of  new  programs. 
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accomplished  without  reprogramming. 

role  [C]  -  . 

A  set  of  access  rights  that  a  subject  can  acquire. 


root  process  node  [C]  - 

The  initial  process  node  created  when  a  user  logs  on  to  an  APSE  or 
when  a  new  job  is  created  via  the  CREATE_pOB  interface. 


secondary  relatloi  ship  [C]  - 

An  arbitrary  connection  which  Is  established  between  two  existing 
nodes. 


sccur1t>  - 

The  management,  protection,  and  distribution  of  Information. 


security  level  [C]  - 

(TCMX)  The  corblnatlon  of  a  hierarchical  classification  and  a  set  of 
non-hlerarchical  categories  that  represents  the  sensitivity  of 
information. 


security  polity  - 

The  set  ol  laws,  rules,  and  relationships  that  regulate  how  an 
organl zatlon  manages,  protects,  and  distributes  information. 

semantics  U.P]  - 
T  liD 


"Chair  LRJ  - 

Indicates  a  requirement  on  the  definition  of  the  CAIb;  sometimes 
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"shall"  is  followed  by  “provide''  or  “support" ,  in  which  cases  the 
following  two  definitions  supersede  this  one. 

"shall  provide"  [R]  - 

Indicates  a  requirement  for  the  CAIS  to  provide  interfaces s)  with 
prescribed  capabilities. 

"shall  support"  [R]  - 

Indicates  a  requirement  for  the  CAIS  to  provide  interfaces s)  with 
prescribed  capabilities  or  for  CAIS  definers  to  demonstrate  that 
the  capability  may  be  constructed  from  CAIS  interfaces. 

"should"  [R]  -  .... 

Indicates  a  desired  goal  but  one  for  which  there  is  no  objective  test. 

source  node  [C]  - 

The  node  from  which  a  relationship  emanates- 

start  position  (of  a  form  terminal)  [C]  - 

The  position  of  a  form  identified  by  row  one*  column  one. 

structural  node  [C]  - 

A  node  without  contents.  Structural  nodes  are  used  strictly  as  holders 
of  relationships  and  attributes. 

subject  [C]  - 

(TCSECr  An  active  entity,  generally  In  the  form  of  a  person, 
process,  or  device,  that  causes  Information  to  flow  among 
objects  or  changes  the  system  state.  In  the  CAIS,  a  subject  is  always 
a  process, 

suspend  [R]  - 

To  stop  the  execution  of  a  process  such  that  it  can  be  resumed.  *n 
the  cortext,  of  an  Ada  program  being  executed,  this  Implies  the 
suspension  of  all  tasks,  a.nd  the  prevention  of  the  activation  of 
any  task  until  the  process  is  resinned.  It  specifically  does  not  imply 
the  releas:  of  any  resources  whlcn  a  process  has  assigned  to  It, 
or  which  It  has  acquired,  to  support  its  execution. 

system-level  node  [C]  - 

The  root  of  the  CAIS  primary  relationship  tree  which  spans  the  entire 
node  structure. 


target  - 

( K/K )  A  target  is  a  computer  system  upon  which  Ada  programs  execute. 
Remark:  Hosts  are,  In  fact,  mso  targets.  In  n  much  as  tne  APSE  is 
written  In  Ado.  A  target  might  r.o .  be  capable  of  supporting  an  APSE. 
An  embedded  target  Is  a  target  which  Is  used  in  mission  critical 
application;.  Examples  of  embedded  target  computer  systems  ore 
AN/AYK-14 ,  AN/UYK -4 3  and  computer  systems  conforming  to 
MIL-SUM 7 bOA  arid  MIL-STb-lbb?.  (NCbJlA). 


target  node  [C]  - 

The  node  at  which  a  relationship  tenni rates. 


task  U]  - 

(UM)  A  task  operates  In  paiallel  with  other  parts  of  the  program. 
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task  wait  [R]  - 

Delay  of  the  execution  of  a  task  within  a  process  until  a  CAIS  service 
requested  by  this  task  has  beer;  performed.  Other  tasks  in  the  same 
process  are  not  delayed. 


terminal  [R]  - 

An  interactive  input/output  device. 


terminate  [R]  - 

To  stop  the  execution  of  a  process  such  that  it  cannot  be  resumed. 


termination  of  a  process  [C]  - 

Termination  (see  [LRfo]  9.4)  of  the  execution  of  the  subprogram 
which  is  the  main  program  (see  [LRM]  10.1)  of  the  process. 


token  [C]  -  An  internal  representation  of  an  identifier  which  can  be 
manipulated  as  a  list  item. 


tool  [C]  - 

(IEEE  -  software  tool)  A  computer  program  used  to  help 
develop,  test,  analyte,  or  maintain  another  computer  program 
cr  its  documentation;  for  exampie,  an  automated  design  tool, 
compiler,  test  tool,  or  maintenance  t,col. 

top-level  node  [C]  « 

A  structural  noae  representing  the  user.  Each  user  has  a  top-level 
node. 

traceability  [CP]  - 
T!3D 

track  [C]  - 

U)  An  open  noue  handle  is  guaranteed  always  to  refer  to  the  same 
node,  regardless  of  any  changes  to  relationships  that  could  cause 
pathnames  to  become  Invalid  or  to  refer  to  different  nodes.  An  open 
r.obe  handle  is  said  to  tracx  the  node  to  which  It  refers.  (2)  Secondary 
relationships. 

transportability  [G]  - 

(K/K)  Transpcrtabll 1 ty  of  an  APSE  tool  Is  ability  of  the  tool 
to  be  installed  on  a  different  KAPSC;  the  tool  must  perform 
with  the  same  functionality  In  both  APSEs.  Transportability  is 
measured  in  the  degree  to  which  this  Installation  can  be 
accomplished  without  reprogramming.  Portabi 1 i ty  and  transferability 
are  commonly  used  synonyms. 

traversal  of  a  nod/*  [C]  ■  Traversal  oi  a  relationship  i-nanating  from  the  node. 

traversal  ->f  a  relal ionshlp  fC]  -  The  act  of  following  a  relationship  from 
Its  source  nodr  to  its  targe?  node. 

typc-ahc,.d  [Rj  - 

The  ability  oi  a  producer  to  transmit  data  units  before  the  consumer 
requests  the  data  units. 

typing  [R]  - 

An  or yiii'Wctlon  of  entitles,  f tlatlcnshlps  and  attributes  in  which 
tnry  are  partitioned  Into  stts,  called  entity  type:,  relationship 
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types  and  attribute  types,  according  to  designated  type  definitions, 
uninterpreted  data  CR]  - 

A  data  representation  whose  structure  is  not  controlled  by  CAIS 
facilities  and  whose  structure  is  not  used  in  the  CAIS  operations. 
Examples  might  be  representations  of  files,  such  as  requirements 
documents,  program  source  code,  and  program  object  code. 

unique  primary  p*th  [C]  - 

The  path  from  the  system-level  node  to  a  given  node  traversing  only 
primary  relationships.  Every  rode  that  is  not  unobtainable  has  a 
unique  primary  path. 

unique  primary  pathname  [C]  - 

The  pathname  associated  with  the  unique  primary  path. 

unnamed  item  [C]  - 

No  name  is  associated  with  a  list  item. 


unnamed  list  [C]  - 

A  list  whose  items  are  all  unnamed. 


unobtainable  LC]  - 

A  node  is  unobtainable  if  it  is  not  the  target  of  any  orimary 
relationship. 

user  [C]  - 

An  individual,  project,  or  other  organizational  entity.  In  the  CAIS 
it  Is  associated  with  a  top-level  node. 


user  name  [C]  - 

The  key  of  ?  primary  relationship  of  the  predefined  relation  USER. 


virtual  terminal  - 

(Davies)  A  conceptual  terminal  which  is  dbfined  as  a  standard 
ior  the  purpose  of  uniform  handling  of  a  variety  of  actual 
termi nal s . 
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STRODUCTIOM 


The  Ada  programmin';  language  u«s  designed  to  feci  1  1  tate  the  use  of 
modularity,  information  hiding,  exception  handling,  parallel  proc¬ 
essing,  ofc>3traction  and  other  software  engineering  concepts  by  pro¬ 
viding  direct  support  to  these  techniques  throughout  the  entire 
application  development  process.  In  support  of  this  goal,  the  Ada 
language  ups  intended  to  be  one  part  of  a  support  environment.  In 
order  for  the  Ad*  Programming  Support  Environment  (APSE)  to  provide 
a  rich  set  of  tools  which  are  both  extensive  and  cost-effective, 
t h .2 !- o  must  be  a  mechanism  whereby  tools  can  be  easily  ported  among 
hoot  development  systems. 

The  Common  APSE  Interface  Set  (CAIS)  provides  specifications  for  a 
set  of  Ada  packages  which  are  designed  to  promote  interoperability 
and  transportabi 1  i  tv  of  Ada  software  development  tools  from  one 
host  development  environment  to  another.  The  CAIS  document  defines 
i nteroperebi 1 i ty  as  the  ability  of  APSEs  to  exchange  data  base 
objects  and  their  relationships  i  r,  forms  usable  by  tools  and  user 
programs  without  conversion.  Transpor tabi 1 i ty  is  defined  as  tha 
ability  cf  the  tool  to  be  installed  on  a  different  Kernol  APSE 
(KAPSE)  with  the  same  degree  of  functionality  in  both  systems. 

The  purpose  of  this  investigation  is  to  evaluate  an  implementation 
cf  a  subset  of  the  CAIS  interfaces,  several  small  CAIS  tools  and  a 
command  line  interpreter  (CLI).  In  order  to  accomplish  this  goal, 
the  investigation  can  be  broken  down  into  the  following  four  phases: 

•  Define  a  subset  of  the  CAIS  sneci f icationu  which  is  robust 
enough  to  demonstrate  most  of  the  features  of  the  CAIS. 

•  Implement  tha  CAIS  subset  on  the  Virtual  Machine  /  Conversa¬ 
tional  Monitor  System  (VlVCMS)  operating  system  running  on  un 
IBM  S/370  computer. 

•  Develop  several  snail  CAIS-like  tools  to  aid  in  the  evaluation 
of  ^thq  CAIS  package:*, 

«•  Develop  a  command  J.ine  interpreter,  a  tool  whose  function  is  to 
interactively  allow  the  user  to  access  the  CAIS  interfaces  and 
invoke  thu  CAIS  tools. 

Tho  CAIS  subset  con  then  be  evaluated  with  respect  to  each  of  the 
different  areas  of  interest  whicn  will  be  elaborated  in  the  approach 
section.  There  «rg  espocts  of  the  CAIS  which  will  not  ho  included 
in  the  scope  cf  this  investigation,  but  which  wore  taken  into 
account  during  the  design  and  development  of  the  CAIS  subnet  imple- 
mentation.  Thus  the  capabilities  rauuirod  to  enhance  this  investi¬ 
gation  can  easily  be  incorporated  into  the  present.  Implementation. 
These  areas  are  summarized  as  follows: 

•  Implement  tho  CAIS  subset  on  the  Multiple  Virtual  Machine  /  Time 
Sharing  Option  (MVB/TSO)  operating  system  running  on  an  IBM 
S/  3  7  Q  compvi  ter  . 

•  Enhance  the  f unt'  i ona 1 i ty  of  the  commund  line  interpreter  to 
nuppor  t  multiple  -,er  a  simultaneously. 

•  Port  the  tools  wr  itten  for  the  VfVCMS  CAIS  system  to  the  MVS/ISO 
CAIS  system. 

Thusu  enhancements  would  allow  lateral  other  aspects  of  the  CAIS 
interfaces  to  be  evaluated.  Thv  degree  to  which  an  implementation 
of  thu  CAIS  dr.pends  on  tire  host  operating  system  can  he  determined 
when  parting  the  VfvChS  version  of  the  CAIS  to  MVJ./1S0.  The  Issues 
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of  access  control  and  security  can  be  examinad  whan  supporting 
several  users  on  the  same  CAXS  database  at  the  same  time.  The 

degree  to  which  the  CAIS  fulfills  the  objective  of  making  tools  fi 

portable  can  bn  evaluated  by  examining  the  difficulties  and  amount  H 

of  ehangus  needed  to  port  the  CAIS  tools  from  the  VIVCMS  system  to  m 

the  MVS/TSO  system. 
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APPROACH 


The  proposed  CAIS  policies  explain  that  the  principal  purpose  of  the 
current  release  of  the  CAIS  specification  is  to  allow  implementors 
to  evaluate  tha  CAIS  interfaces  as  one  component  of  an  Ada  prograM- 
ming  support  environment.  This  investigation  was  designed  to  eval¬ 
uate  the  CAIS  in  etch  of  the  following  three  areas: 

•  An  effort  was  made  to  implement  e  subset  of  the  CATS  interfaces. 
This  was  done  to  demonstrate  the  capability  of  the  given  inter¬ 
faces  to  provide  a  l^vel  of  functional i ty  sufficient  to  accom¬ 
plish  the  objectives  of  the  CAIS. 

•  Tools  were  written  which  run  on  top  of  a  CAIS  implementation  and 
depend  on  the  CAIS  interfaces  exclusively;  that  is>  the  tools 
function  without  regard  to  the  underlying  operating  system. 
These  were  used  to  evaluate  the  usablity  of  the  CAIS  interfaces 
from  the  point  of  view  of  a  tool  writer. 

•  A  commend  line  interpreter  was  developed  to  allow  the  user  to 
access  the  CAIS  interfaces  and  invoke  the  CAIS  tools  interac¬ 
tively.  In  this  manner,  the  CAIS  subset,  together  with  the  CAIS 
tools  which  were  written  for  the  investigation,  was  examined 
and  evaluated  while  running  as  a  complete  software  development 
eriv  i  ronment . 

These  throe  areas  provided  a  means  to  evaluate  the  CAIS  interfaces 
with  respect  to  a  number  of  different  criteria: 

e  Perf  orHiaftwe  -  T,i«  Fsapvn-je  time  nacaosary  for  a  particular 
operation  should  not  be  significantly  increased  by  the  overhead 
necessary  for  tho  CA15  to  maintain  the  node  model. 

•  Efficiency  -  The  CAIS  implementation  should  make  an  optimal 
balance  between  the  time  and  space  resources  involved. 

•  Usability  -  The  CAIS  should  be  both  natural  and  understandable 
in  its  interfaces  to  the  user  and  the  CAIS  tools. 


Viability  -  It  should  be  a  fairly  strai ghtforwerd  process  to  add 
functionality  to  the  CAIS  system  as  new  capabilities  are 
des i red . 


Feasibility  -  Thu  CAIS 
end  natural  «*pp— c«gm  to 


interfaces  should  be  a  reasonably  simple 

_ _ a.  : _ a  n  r  r - :  i  1  — 

I  tc \j »  »»icii  i  i  ny  nr  villi  l  I  « 


Reliability  -  Error  conditions  which  occur  in  either  the  CAIS 
interfaces  or  any  CAIS  tools  should  be  handled  in  such  a  way  as 
to  prevent  any  exception  from  compromising  the  data  integrity 
of  the  node  model. 


•  Completeness  -  The  system  should  not  require  anv  resources  or 
interfaces  which  are  not  available  from  tha  CAIS  specifica¬ 
tions. 


Approach 
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C A I S — SUBS ET  DEFINITION 


This  section  describes  the  issues  end  difficulties  found  in  select¬ 
ing  the  interfaces  which  worn  included  in  the  CA1S  subset  end  the 
rationale  for  the  decisions  made  during  this  process. 


CATS  INTERFACES  SUPPORTED 


The  subset  was  defined  with  the  intention  of  supporting  most  of  the 
features  of  the  CA1S.  This  would  enable  the  evaluation  to  work  on  a 
realistic  subset;  that  is*  the  subset  must  be  robust  enough  to  *ccu~ 
rately  reflect  a  typical  CAIS  environment. 

The  hierarchical  node  model  representing  APSE  entities  consisting 
of  file,  structural  and  process  nodes  is  fully  supported.  Linkages 
between  nodes  in  the  form  of  primary  and  secondary  relations  are 
also  fully  supported.  The  nodes*  together  with  the  relationships 
that  link  them,  form  the  basis  for  the  CAIS  representation  of  APSE 
enti ti es. 

Attributes  are  supported  for  both  nodes  and  relationships  in  the 
CAIS  subset  to  describe  the  characteristics  of  entities  in  the  node 
model.  These  interfaces  were  considered  highly  important*  as  they 
would  undoubtedly  be  used  by  most  CAIS  tools  in  an  actual  CAIS  envi¬ 
ronment  . 


The  CAIS  spec; f i ecti sn  includes  support  for  page.-  scroll  end  form 
terminals.  However,  only  the  f orm^termi nal  package  was  included  in 
the  CAIS  subset,  since  one  kind  of  terminal  support  would  be  suffi¬ 
cient  for  the  investigation.  Form  terminal  support  was  chosen 
because  the  development  of  the  subset  was  performed  on  IBM  3270 
series  terminals,  which  are  form  terminals. 


Single-volume  labeled  and  unlabeled  magnetic  tape  files  are  sup¬ 
ported  by  the  magnet i c_tape  package  of  the  CAIS  specification.  The 
package  was  designed  to  conform  to  level  2  of  the  ANSI  78  standard. 
This  package  was  considered  important*  but  not  necessary,  to  the 
investigation  of  the  CAIS*  because  it  demonstrates  the  ability  of 
the  CAIS  to  support  a  specific  type  of  device  in  accordance  with  a 
separate  standard.  This  is  also  important  in  that  it  shows  how 
future  enhancements  may  be  easily  made  to  the  CAIS  to  suppnrt  more 
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MIL.  INTERFACES  HUT  SUPPORTED 


Some  of  the  features  of  the  CAI5  were  not  included  in  the  implemen¬ 
tation,  as  they  were  not  considered  necessary  to  the  scope  of  this 
i nvest i gat i on . 

To  er.forco  security  in  a  CAIS  environment,  the  CAIS  provides  a  sat 
of  interfaces  to  support  mandatory  end  di screti unary  access  con¬ 
trols.  handatory  access  control  is  defined  in  the  CAIS  as  being  a 
nut  of  controls  based  directly  on  a  comparison  of  the  i  nd(_v  i  due  1  '  * 
claoi ence  or  «u tho r i z» t > on  for  the  information  and  the  classifica¬ 
tion  or  sensitivity  designation  of  the  information  being  sought. 
Di  acrex  I  ontiry  access  control  Is  a  means  of  restricting  access  to 
objects  based  on  tire  identity  of  subjects  and/or  proups  to  which 
they  belong.  Although  the  capability  is  present  in  the  chosen  sub“ 
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set  to  support  discretionary  access  controls  through  the  us*  of  node 
and  relation  attributes,  those  attributes  are  not  predefined  and 
enforced  by  the  implementation. 

Invocation  of  processes  is  not  supported  on  the  VM/CMS  implementa¬ 
tion  of  the  CAIS  subset  because  of  the  single-process  neture  of 
VM/CMS.  Howevett  process  nodes  ere  supported  by  the  implementation 
and  full  process  support  could  be  added  in  the  future  cn  an  MVS/TSO 
implementation.  Thus,  although  processes  ere  not  actually  spawned 
by  tha  CAIS  implementation,  this  activity  can  be  simulated  and  the 
dummy  processes  can  be  tracked  through  the  use  of  process  nodes. 

The  text_ie.  directive,  and  sequent i al_i o  input/output  packages 
defined  i*n  the  CAIS  specification  are  not  supported.  Instead  of 
implementing  the  CAIS  input/output  packages,  a  new  interface  was 
defined  to  implement  only  those  procedures  which  differ  from  the 
predefined  Ada  packages. 

Support  for  page  and  scroll  terminals  was  excluded  in  favor  of  form 
terminals,  since  IBM  3270  series  terminals  were  used  during  the 
i nvesti gnti on ,  and  a  single  type  of  terminal  support  was  sufficient 
for  the  scope  of  this  investigation. 


INTERFACES  ADDED  TQ_THE  CAIS  SUBSET 


In  some  cases,  interfaces  were  defined  which  were  not  in  direct  sup¬ 
port  of  tha  CAIS  specification,  in  order  to  deal  with  difficulties 
in  implementing  the  CAIS  interfaces. 

An  Ada  package  called  file„nodes  was  added  to  interface  to  text_io, 
direct_io,  and  sequent i al_i o ,  the  predefined  Ada  input/output  pack¬ 
ages.  This  package  provides  support  to  create  file  nodes,  similar  to 
tha  structural_nodes  package  defined  in  the  CAIS  specification. 
The  package  implements  all  of  the  input/output  procedures  which 
require  parameters  of  type  node_type,  since  these  procedures  differ 
from  the  predefined  Ada  packages.  This  allows  the  CAIS  to  utilize 
the  predefined  Ada  packages  directly. 

An  Ada  package  called  ca  i  s_add?  ti  onal_ut  i  I  i  t  i  «sa  was  added  to  define 
all  functions  and  procedures  required  by  this  implementation  that 
were  not  supported  by  tho  CAIS  specification.  These  include  support 
tor  backing  up  the  CAIS  database  to  a  set  of  disk  files  and  restoi — 
ing  them  to  resident  memory,  end  any  associated  functions  and  proce¬ 
dures  which  were  necessary  to  the  implementation  of  the  CAIS  subset, 
but  which  were  not  included  in  the  CAIS  specification. 
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CAIS  COMMAND  LINE  INTERPRETER 


The  Command  Line  Interpreter  is  •  set  of  utilities  controlled  by  * 
small  driver  routine  which  allow  the  user  to  interactively  access 
the  CAIS  interfaces  and  invoke  the  CAIS  tools.  Over  the  course  of 
this  investigation,  the  CLI  changed  and  matured  greatly.  At  first, 
the  CLI  simply  allowed  the  user  to  type  in  simple  commands  to  create 
and  delate  structural  nodes.  Additional  capabilities  were  added 
over  the  course  of  the  investigation  until  the  CLI  was  a  powerful 
tool  capable  of  supporting  all  of  the  CAIS  interfaces  as  well  as 
invoking  the  various  CAI?  tools. 


The  CLI  became  a  full-screen  interactive  CAIS  environment  drivor. 
The  user  interface  was  supported  by  both  a  command  line  and  a  com¬ 
plete  menu-driven  interface  and  was  divided  into  four  areas  as  shown 
in  the  following  diagram: 


AREA  1:  On  the  left  part  of  the  screen,  items  could  be  selected 
from  a  set  of  menus  listing  all  of  the  CAIS  operations  end 
CAIS  tools.  Manus  could  be  scrolled  forwards  and  back¬ 
wards  with  function  keys. 

AREA  2:  In  the  center  third  of  the  screen  various  parameters 
describing  the  state  of  the  CAIS  environment  ware  dis¬ 
played.  These  included  the  current  time  and  date,  the 
total  number  of  nodes  in  the  system,  the  number  of  nodes 
owned  by  the  user,  the  number  of  users  in  the  system,  the 
number  of  operations  which  had  occurred  since  the  last 
time  the  system  was  backed  up  and  the  time  of  the  next 
scheduled  backup. 

AREA  3:  The  right  part  of  the  screen  displayed  the  kinds,  relation 
names  and  relationship  keys  of  the  nodes  representing  the 
current  user,  the  current  node  under  that  user,  and  the 
children  described  by  primary  links  originating  from  the 
current  node. 


AREA  4:  The  bottom  of  the  screen  was  used  as  a  command  line  where 
the  user  could  type  in  requests  directly  rather  than  use 
the  menus.  This  area  was  also  used  whenever  the  CLI 
prompted  the  user  for  an  input  string,  such  as  a  file  name 
or  a  relationship  key. 


A  separate  screen  could  be  activated  to  display  all  of  the  informa¬ 
tion  about  the  current  node  including  the  names,  types  and  values  of 
the  node  and  relation  attributes,  the  name  of  the  host  file  associ¬ 
ated  with  the  node’s  contents  and  the  kind,  relation  name  and 
relationship  key  of  the  node's  parent. 


By  allowing  the  user  to  interactively  access  the  CAIS  interfaces, 
the  commend  line  interpreter  provided  a  means  for  the  CAIS  database 
to  be  built  and  tested  before  tools  were  available.  This  greatly 
facilitated  the  debugging  process  of  the  interfaces,  since  many 
different  operations  could  be  attempted  and  their  results  on  the 
node  model  could  be  examined.  The  implementation  of  the  CAIS  inter- 
*  faces  would  have  progressed  much  more  slowly  had  i  <■  been  necessary 
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to  writs  small  driver  routings  to  tast  each  of  the  procedural  as 
they  ware  developed. 
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CAIS  TOOLS 


As  the  CAIS  subset  matured  to  the  point  where  file  nodes  and  the 
import  and  export  procedures  were  supported,  it  became  possible  to 
begin  testing  tools  in  the  CAIS  environment.  Several  smoll  tools 
were  developed,  including  an  Ada  source  line  counter  and  a  pretty 
printer.  Initially#  these  tools  could  only  be  invoked  from  within 
the  command  line  interpreter.  As  the  ClI  developed  more  capabili¬ 
ties.  more  tools  were  integrated#  including  e  stubber,  e  more  power¬ 
ful  pretty  printer#  a  compiler  batch  submissions  tool  and  support 
for  two  full-screen  editors.  Support  was  added  in  the  command  line 
interpreter  to  allow  the  user  to  invoke  these  tools  interactively# 
with  several  different  levels  of  functionality.  These  different 
levels  ware  designed  to  give  the  tools  more  and  mora  responsibility 
to  access  the  node  model#  thereby  allowing  the  tools  to  be  tested 
end  developed  with  successive  increases  in  functionality.  These 
classes  of  interfaces  are  as  follows: 


LEVEL  1:  At  the  minimal  level  of  CAIS  functionality#  e  given  tool 
would  work  directly  with  a  host  file.  The  command  line 
interpreter  would  export  the  file  from  the  current  node# 
and  that  file  would  be  passed  as  input  to  the  tool.  This 
allowed  non-CAIS  tools  to  be  used  at  this  stage  of  inves¬ 
tigation#  since  the  tools  had  no  access  to  the  CAIS  inter¬ 
faces. 

LEVEL  2:  The  current  node  was  opened  by  the  command  line  interpret¬ 
er  and  passed  tc  the  CAIS  tool  as  input.  The  tool  was 
responsible  only  for  extracting  the  host  file  from  the 
node's  contents  and  had  no  direct  contact  with  the  node 
model.  The  results  of  the  operation  performed  by  the  tool 
ware  put  into  a  file  which  the  tool  then  passed  back  to 
the  CLI.  The  CLI  would  then  create  a  new  node  as  a  child 
of  the  current  node  and  import  the  results  file  to  the  new 
node. 


LEVEL  3:  The  commend  line  interpreter  passed  the  current  node  to 
the  tool,  which  would  extract  the  file,  perform  its  oper¬ 
ations,  creato  a  results  file,  create  a  new  node  and 
import  the  results  file  to  the  new  node.  This  is  the 
first  level  at  which  the  tool  itself  changed  the  CAIS 
database . 

LEVEL  4:  At  the  final  level  of  tool  development#  the  command  line 
interpreter  would  simply  pass  control  over  to  the  tool 
when  the  user  invoked  it.  Thetool  would  be  responsible 
for  oil  interaction  with  the  CAiS  database,  when  the  tool 
was  finished#  it  would  pass  control  back  to  the  CLI.  This 
level  of  responsibility  is  equivalent  to  a  tool  running 
by  itself  without  a  command  line  interpreter. 

The  method  of  iterative  development  of  tools  proved  extremely 
informative  in  that  the  difficulties  of  writing  tools  could  be  exam¬ 
ined  in  several  stages.  This  provides  a  much  more  thorough  examina¬ 
tion  of  the  usability  of  the  CAIS  interfaces  from  the  point  of  view 
of  the  tool  writer  than  if  the  tools  hod  simply  been  developed  in 
one  pass  and  evaluated  after  they  were  completed.  Integrating  tools 
in  an  iterative  fashion  displayed  very  clearly  the  tradeoffs 
between  the  level  of  functionality  of  the  tools  and  the  level  of 
difficulty  in  implementing  the  tools.  This  could  be  considered  to 
be  a  measure  of  the  usability  of  the  CAIS  interfaces#  which  is  an 
extremely  subjective  characteristic  and  hence  difficult  to  evalu¬ 
ate. 


CAIS  Tools 


3-576 


EVALUATION 


The  entire  procsss  of  defining  a  subset,  implementing  the  subset,, 
dovaloping  several  CAIS  teals  and  developing  a  command  line  inter¬ 
preter  proved  extremely  useful  in  evaluating  the  CAIS  specifica¬ 
tion,  One  of  the  most  important  aspects  of  the  investigation  was 
the  iterative  approach  which  was  used.  This  approach  allowed  tha 
CAIS  to  be  developed  at  the  same  time  as  the  command  line  interpret¬ 
er  and  tha  tools,  in  a  series  of  iterations  which  provided  input  to 
tha  evaluation  at  each  step  of  the  investigation. 

At  the  completion  of  the  investigation,  there  was  a  total  of  over 
sixteen  thousand  lines  of  Ada  source  code  running  in  the  CAIS  envi¬ 
ronment.  Lines  of  coda,  for  the  purposes  of  this  measurement, 
included  fewer  than  five  percent  comments  and  blank  lines  and  a  sin¬ 
gle  Ada  statement  which  ran  over  several  records  would  be  counted  as 
several  lines  of  code.  The  code  can  be  broken  up  into  several  basic 
categories  to  gain  a  better  understanding  of  the  size  of  the  inves¬ 
tigation: 


CAIS  Interfaces 

Command  Line  Interpreter 
CAIS  Tools 

Terminal  Interface 

3, If  4  1 ines 

2,854  linns 

5,137  lines 

4,946  lines 

Total 

16,101  lines  of  code 

The  evaluation  of  this  investigation  was  broken  up  into  threa  areas: 
tha  CAIS  subset,  the  command  line  interpreter  and  the  CAIS  tools. 


The  two  basic  criteria  that  were  used  in  selecting  a  subset  of  the 
CAIS  interfaces  to  be  implemented  for  this  investigation  were  that 
the  subset  defined  should  be  robust  enough  to  demonstrate  most  of 
the  features  of  the  CAIS  and  simple  enough  to  be  implemen  ted  in  a 
reasonably  short  amount  of  time.  Some  tradeoffs  were  necessary  to 
achieve  a  reasonable  balance  between  these  two  objectives.  For 
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to  be  included  in  the  subset,  since  support  of  one  type  of  terminal 
would  be  sufficient  to  demonstrate  the  ability  of  the  CAIS  inter¬ 
faces  to  support  terminals. 


Initially,  an  extremely  severe  subset  was  defined  and  implemented. 
This  subset  included  only  those  interfaces  necessary  for  the  cre¬ 
ation  and  deletion  of  structural  nodes  and  for  defining  primary 
links  between  the  nodes.  This  allowed  tha  testing  of  various  data 
structures  to  represent  nodes  and  relationships,  without  requiring 
a  large  amount  of  programming  when  changing  data  structures.  After 
the  implementation-defined  data  structures  were  finalized,  the 
iteration  process  began  whereby  the  CAIS  interfaces  end  the  command 
line  interpreter  would  be  developed  in  parallel  in  order  to  facili¬ 
tate  the  testing  and  integration  of  the  interfaces.  When  tho  CAIS 
interfaces  hod  matured  to  the  point  of  supporting  file  nodes  and 
their  manipulation,  several  simple  CAIS  toils  were  defined  ana 
their  development  was  included  in  the  iterative  process. 

By  employing  successive  increments  in  the  level  of  functionality  of 
tha  CAIS  intarfaces  and  including  thorough  testing  through  the  use 
of  the  comments  line  interpreter  as  a  oriver  for  the  interfaces,  the 


Eva  1 ua t i on 


3-577 


original  subsat  was  gradually  enhanced  until  it  raachad  its  final 
form.  In  tha  ordar  in  which  tha  intarfacas  wars  added,  tha  final 
subsat  of  tha  CAIS  intarfacas  uitd  in  this  i nvasti gati on  included 
structural  nodes,  primary  links,  fila  nodas.  fila  import  and  export 
oparations,  sacondary  links,  full  noda  management  s'oport,  form 
terminal  support,  process  nodes,  list  utilities,  ode  attributes, 
Ada  input/output  support,  relation  attributes,  backup  and  restora¬ 
tion  of  the  CAIS  system  and  magnetic  tape  support. 

The  final  subset  included  most  of  the  features  of  the  CAIS,  but 
several  were  deliberately  axcluded  from  tha  scope  of  the  investi¬ 
gation.  These  interfaces  include  those  for  security,  process  con¬ 
trol  and  input/output  operations. 

Security  was  not  included  in  tha  subsat  because  the  scope  of  the 
investigation  was  limited  to  a  single-user  environment,  host  of  the 
discretionary  access  controls  are  much  more  appropriately  addressed 
in  a  multi-user  environment.  Tha  attribute  operations  provide  a  set 
of  interfaces  which  can  easily  be  used  for  across  control,  however, 
and  tha  attribute  operations  are  fully  supported  by  the  final  sub¬ 
set. 

Process  nodes  can  be  created  in  the  final  subset,  although  real  pro¬ 
cesses  are  not  actually  spawned  as  part  of  the  creation  operation. 
Through  tha  use  of  attributes,  all  of  the  pertinent  characteristics 
of  processes  can  be  maintained,  such  as  the  start  end  stop  times. 
The  reason  the  processes  are  not  actually  spawned,  but  merely  simu¬ 
lated,  is  that  the  VM/CMS  operating  system  which  this  CAIS  implemen¬ 
tation  runs  on  does  not  support  multiple  processes  running  on  a 
single  virtual  machine.  Thus,  only  the  tracking  and  simulation  of 
processes  is  included  in  the  CAIS  subset. 

Instead  of  supporting  the  three  input/output  packages  defined  in 
thQ  CAIS  specification,  tha  subset  defined  a  new  interface  which 
imported  the  three  predefined  Ada  packages.  This  decision  was  not 
mode  because  the  CAIS  interfaces  were  considered  inappropriate,  but 
becouse  of  the  time  restraints  imposed  on  the  development  of  the 
CAIS  subset.  A  small  package  could  easily  be  defined  to  extract  the 
host  file  from  the  file  node  and  allow  tha  predofinad  Ada  packages 
to  operate  on  the  host  file,  without  performing  an  export  operation. 
In  this  manner,  a  tool  would  operate  just  as  if  it  were  performing 
input  and  output  operations  on  the  contents  of  a  node,  but  would 
actually  be  working  with  the  host  file  represented  by  the  contents 
of  the  node.  This  was  considered  to  be  an  acceptable  compromise, 
allowing  support  of  the  input  and  output  functionality  described  by 
the  CAIS  specification  without  requiring  the  actual  implemantati on 
of  these  throe  packages. 

In  order  to  maintain  a  file-based  copy  of  the  CAIS  system,  several 
interfaces  were  added  to  the  subset  to  support  the  backing  up  and 
restoration  of  the  nodes  and  relationships.  Thrse  procedures  would 
save  and  restore  all  of  the  information  contained  in  the  data  struc¬ 
tures  which  represented  the  node  model  in  several  host  files  using 
direct  and  sequential  input/output  operations. 


CAIS  COnWAKP  LINS  INTERPRETER  ■ 


The  command  line  interpreter  provided  a  means  to  devolop  a  very  usa¬ 
ble  application  programming  environment  based  on  the  CAIS  Jnter- 
faces.  This  provided  a  great  deal  of  valuable  input  about  the 
usability, _  performance,  efficiency,  viability  and  reliability  of 
the  CAIS  interfaces  from  the  point  of  view  of  the  user.  The  CLI 
proved  to  be  an  extremely  flexible  end  powerful  tool  for  running  a 
CAIS  environment.  For  approximately  the  last  two  months  of  this 
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investigation.  whan  it  had  matured  enough  to  make  usage  possible, 
the  CA1S  environment  Mas  driven  by  the  ClI  and  actually  used  as  the 
development  environment  for  this  project. 

In  order  to  use  the  CAIS  as  a  true  development  environment,  it  was 
necessary  to  integrate  two  non-Ada  tools,  an  Ada  compiler  batch  sub¬ 
mission  tool  and  a  full-screen  editor,  into  the  CAIS  system. 
Although  these  tools  Mere  not  developed  into  CAIS  tools,  they  Mere 
considered  valuable  to  the  investigation  baeauso  they  alloMod  the 
CAIS  to  be  used  as  a  working  anvironment.  rather  than  just  an  axper- 
imentol  set  of  interfaces. 

All  of  the  other  tools  end  many  of  the  non-critical  CAIS  interfaces 
were  developed,  tasted  and  integrated  from  within  the  running  CAIS 
environment.  The  CLI  allowed  thi  user  to  edit  source  programs, 
print  hard  copies,  compile  Ada  cede,  test  new  routines,  and  inte¬ 
grate  them  into  the  running  environment.  The  command  line  inter¬ 
preter  itself  was  improved  and  modified  from  within  the  CAIS 
environment.  The  development  of  these  tools  and  interfaces  showed 
that  the  CAIS  interfaces  can  be  used  to  define  an  application  pro¬ 
gramming  environment  which  is  very  usable  from  the  user's  point  of 
view. 

It  is  a  subjective  effort  to  try  to  evaluate  the  usability  of  the 
CAIS.  so  no  qualitative  measurement  will  be  attempted,  but  it  can  be 
said  that,  in  general,  the  CAIS  environment  was  no  more  difficult  to 
understand  and  use  than  a  typical  operating  system.  Of  course,  the 
subset  of  the  CAIS  used  in  this  investigation  was  not  nearly  as  pow¬ 
erful  as  a  typical  operating  system,  nor  did  it  provide  many  of  the 
functions  of  an  operating  system,  but  it  did  prove  to  be  extremely 
fast  and  reliable. 

The  performance  and  efficiency  of  the  C17  proved  to  be  much  higher 
than  anticipated.  Far  nearly  all  of  the  operations  which  involved 
the  CAIS  interfaces,  the  response  time  was  immediate.  CAIS  oper¬ 
ations  were  performed  as  fast  as  they  could  be  typed.  The  reason 
for  this  performance  lies  in  the  fact  that  the  CAIS  database  was 
maintained  both  in  host  files  and  in  data  structures.  All  CAIS 
operations  were  carried  out  on  the  data  structures  in  memory  and 
only  when  the  system  was  backed  up  did  these  changes  get  reflected 
in  the  host  f i les. 

The  issue  of  reliability  was  resolved  by  maintaining  the  file-based 
backup  copy  of  the  CAIS  database.  The  backup  end  restore  procedures 
each  took  about  one  minute  to  executa,  but  this  was  considered  to  be 
«  reasonable  tradeoff  for  the  increase  in  reliability  gained  by  hav¬ 
ing  a  file-based  copy  of  the  database.  Instead  of  losing  tho  entire 
CAIS  database  if  the  computer  suffered  a  power  failure,  for  example, 
all  that  would  be  lost  ere  those  operations  which  occurred  after  the 
last  time  the  system  was  becked  up.  The  CLI  would  automatically 
backup  the  database  at  regular  intervals.  Also,  after  any  partic¬ 
ularly  important  operation,  the  user  could  request  that  the  system 
be  backed  up  immediately.  In  this  manner,  very  few  CAIS  operations 
would  ever  be  lost,  so  the  CAIS  environment  had  a  high  degree  of 
reliabi li ty . 

In  one  respect,  this  method  of  maintaining  two  copies  of  the  CAIS 
database  was  even  more  reliable  than  a  purely  file-based  CAIS.  In  a 
file-based  system  it  would  be  difficult  to  recover  if  for  any  reason 
the  data  integrity  of  the  CAIS  database  was  compromised.  In  the 
two-copy  environment,  however,  all  that  needs  to  be  done  if  the 
database  is  compromised  is  to  restore  the  most  recent  backup  of  the 
database. 

The  command  line  interpreter  proved  to  be  extremely  valuable  in  the 
evaluation  of  the  CAIS.  By  allowing  tl.e  user  to  interactively 
invoke  the  CAIS  interfaces  and  tools,  it  assisted  greatly  in  the 
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tasting  and  integration  of  the  interfaces.  In  addition*  it  permit" 
ted  the  CAIS  environment  to  be  used  as  the  application  programming 
environment  for  much  of  the  investigation,  thereby  gaining  much 
insight  into  the  areas  of  performance  and  reliability.  Overall,  the 
command  line  interpreter  can  be  considered  a  very  natural  and  power¬ 
ful  tool  in  the  development  and  testing  ol  a  CAIS  environment. 


CAIS  TOOLS 


The  tools  developed  for  this  project  were  deliberately  chosen  to 
represent  a  wide  range  of  capabilities  and  complexity.  Ranging  from 
the  simplest  to  the  most  complex,  they  included  an  Ada  source  line 
counter,  a  basic  pretty  printer,  e  body  stubber,  an  Ada  compiler 
batch  submissions  tool,  a  complex  pretty  printer  and  two 
full-screen  editors. 

The  change  in  si2e  of  each  of  the  tools  over  the  course  of  the 
investigation  is  shown  in  the  following  table,  broken  down  into  the 
four  levels  of  responsibility.  As  an  example,  the  simplest  tool  was 
the  Ada  source  code  line  counter,  which  read  in  a  source  file  and 
produced  a  report  showing  the  number  of  lines  of  Ada  code,  comments, 
semicolons,  blank  lines  end  total  lines  in  the  file.  The  line  coun¬ 
ter  itself  contained  only  85  lines  of  code  at  the  first  level  of 
CAIS  responsibility  discussed  earlier.  This  was  the  level  at  which 
the  tool  had  no  direct  interaction  with  the  CAI5  interfaces.  At  the 
second  level,  with  responsibility  for  read  accesses  to  the  CAIS,  the 
size  of  the  line  counter  increased  to  120  lines  of  code.  Adding  the 
third  level  of  responsibility  increased  the  line  counter  to  185 
lines  of  code.  At  the  fourth  and  final  level,  where  tho  tool  is 
fully  responsible  for  all  interaction  with  ths  CAIS  database,  the 
line  counter  reached  its  maximum  length  at  222  lines  of  code. 


Level 

L  i  no 
Counter 

Pretty 

Printer 

Body 

Stubber 

Batch 
Submi t 

Pretty 

Printer 

Screen 

Editors 

Fi  rst 

86 

887 

852 

N/A 

2430 

N/A 

Second 

120 

930 

899 

XXXX 

2491 

XXXX 

Thi  rd 

182 

1007 

992 

XXX  X 

XXXX 

XXXX 

Fourth 

225 

1039 

XXXX 

XXXX 

XXXX 

XXXX 

The  batch  submissions  tool  and  the  two  full-screen  editors  were  not 
written  in  Ada,  so  their  line  counts  were  not  included.  They  were 
included  in  the  CAIS  environment  because  the  CAIS  system  was  actual¬ 
ly  used  as  a  programming  onv  i  rnnmeni  for  much  of  the  i  rsvest  5  gat  5  Sr, . 
Since  full-screen  editing  and  Ada  compiling  were  both  necessary  for 
any  application  programming  environment,  these  tools  were  neces¬ 
sary,  even  though  they  were  never  developed  beyond  the  first  level. 

The  rest  of  the  tools  that  were  developed  for  this  project  ware 
deliberately  chosen  to  form  o  representative  sat  of  a  large  class  of 
tools;  specifically,  tools  which  read  in  data  from  a  host  file,  pei — 
form  some  function  on  that  data,  create  a  second  host  file  and  write 
the  results  of  the  function  into  tho  second  host  file.  The  line 
counter  is  e  very  simple  example  of  such  a  tool,  while  the  pretty 
printer  is  a  much  more  complex  tool  of  this  same  type.  The  reason 
for  this  choice  becomes  apparent  when  the  attempt  is  made  to  measure 
the  usability  of  the  CAIS  interfaces. 

Usability  is  a  very  subjective  concept,  and  an  cbjective  method  to 
measure  tha  usability  of  the  CAIS  interfaces  from  the  point  of  view 
of  tha  tool  writer  is  difficult  to  specify.  Cne  aspect  of  usability 
which  can  be  measured,  however,  is  the  degree  of  localization  of  the 
changes  required  to  convert  e  non-CAIS  tool  into  a  CAIS  tool.  By 
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modifying  the  tools  in  four  steps  as  described  above,  tha  size  of 
each  tool  was  tracked  throughout  tha  course  of  tha  investigation.  A 
measure  of  the  usability  of  tha  CAIS  interfaces  can  than  be  defined 
as  the  tendency  of  tha  increase  in  size  of  each  tool  to  be  constant 
regardless  of  the  size  of  tha  tool*  as  each  tool  is  developed  in  the 
four  steps.  This  is  because  a  very  usable  interface  would  not 
require  changes  in  tha  structure  or  logic  of  a  tool,  but  only  local¬ 
ized  changes  to  such  areas  as  input/output  and  exception  handling. 
Such  changes  would  involve  around  tha  same  number  of  modifications 
regardless  of  tho  original  size  of  the  tool.  In  short,  then,  if 
each  tool  grew  by  an  amount  proportional  to  the  size  of  the  tool,  it 
would  indicate  a  poor  degree  of  usability.  On  the  other  ha. id,  if 
each  tool  grew  by  a  relatively  constant  number  of  lines,  it  would 
indicate  a  high  degree  of  usability. 

It  is  apparent  from  the  table  that  the  amount  of  change  required  to 
give  the  tools  more  responsibility  was  relatively  constant  regard¬ 
less  of  the  original  size  of  the  tool,  for  example,  the  line  count¬ 
er  increased  by  139  lines  and  the  first  pretty  printer  increased  by 
152  lines,  oven  thojgh  the  pretty  printer  started  out  over  ten  times 
the  size  of  the  line  counter.  The  changes  to  the  tools  in  each  case 
occurred  in  those  areas  which  dealt  with  initialization, 
input/output  and  exception  handling. 

This  suggests  that  many  non-CAIS  tools  could  probably  be  developed 
into  CAIS  tools  in  a  fairly  straightforward  manner  by  changing  the 
initialization,  I/O  and  exception  handling  routines.  The  rest  of 
the  tool  can  be  .left  virtually  unchanged.  Tnis  is  valid  only  for 
tools  which  ora  similar  to  those  used  for  this  investigation,  howev¬ 
er.  A  tool  which  monitors  machine  usage,  for  example,  would  not 
fall  under  this  category. 

It  should  also  be  noted  that  it  takes  less  time  and  effort  to  con¬ 
vert  additional  non-CAIS  tools  into  CAIS  tools,  since  many  of  the 
changes  are  very  similar  to  those  mode  during  the  conversion  of  ear¬ 
lier  tools.  For  example,  it  took  significantly  less  time  to  convert 
the  body  stubber  into  a  CAIS  tool  than  the  line  counter,  because 
much  of  the  work  was  copied  from  the  line  counter  into  the  body 
stubber  with  little  or  no  modification.  This  is  another  indication 
of  the  high  degree  of  usability  of  the  CAIS  intnrfaces. 

Since  production-quality  tools  designed  for  the  CAIS  are  not  yet 
available,  a  likely  alternative  for  implementors  is  to  take  exist¬ 
ing  tools  and  convert  them  into  CAIS  tools.  The  four  successive 
levels  of  responsibility  used  in  this  investigation  proved  to  be 
very  helpful  in  developing  those  tools,  since  they  could  bs  tested 
at  each  level,  with  only  minor  changes  occurring  at  a  time.  The 
CAIS  interfaces  are  very  usable  from  this  standpoint,  sinca  very 
similar  changes  were  made  to  each  tool  to  progress  from  level  to 
level.  Overall,  then,  the  CAIS  interfaces  had  a  high  degree  of  usa¬ 
bility,  as  seen  in  the  objective  measurement  of  tha  degree  of  local¬ 
ization  of  changes  necessary  for  the  conversion  of  a  tool. 
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SUMMARY 


Throughout  the  courji  of  this  Investigation,  particular  attention 
was  paid  to  the  evaluation  of  the  C  A I S  interfaces  from  the  points  of 
view  of  the  CAIS  implementor,  the  CAIS  tool  writer  and  the  user  of 
the  CAIS  environment.  The  design  and  development  of  the  CAIS  sub¬ 
set,  the  command  line  interpreter  and  the  CAIS  tools  all  were  influ¬ 
enced  by  this  objective. 

The  CAIS  interfaces  proved  to  be  fairly  straightforward  and  undei — 
stondable  during  the  implementation  of  the  subset.  The  node  model 
saemed  to  be  a  very  natural  way  .to  represent  the  APSE  entities,  and 
lent  itself  to  several  different  data  structures  in  a  fairly  clear 
und  understandable  way.  This  greatly  aided  the  implementation  of 
the  CAIS  interfaces  during  the  investigation. 

From  the  perspective  of  the  tool  writer,  the  CAIS  proved  usable  in 
that  it  did  not  impose  any  particular  restrictions  or  requirements 
on  the  structure  and  logic  of  the  tool-  Rather,  most  of  the  inter¬ 
actions  with  the  CAIS  interfaces  occurred  in  several  localized 
areas  of  the  tools.  This  greatly  reduced  the  degree  to  which  the 
CAIS  interfaces  had  to  be  considered  when  designing  and  developing 
the  tools.  This  also  allowed  non-CAIS  tools  to  be  converted  into 
CAIS  tools  in  a  straightforward  and  fairly  simple  manner. 

Finally,  the  use  of  the  CAIS  system  as  an  actual  application  pro¬ 
gramming  environment  demonstrated  tha  excellent  response  time  per¬ 
formance,  the  usability  of  the  node  model  and  the  reliability  the 
CAIS  interfaces  are  capable  of  providing  to  the  user  of  the  CAIS 
env i ronment . 


Summary 
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Points  oi  View  for  Evaluation 


IBM 


♦  The  scope  of  this  investigation  was  to 

implement  a  CAIS  environment  sufficient  to 
evaluate  the  CAIS  with  respect  to  three 
points  of  view: 


—  CAIS  Implementor 


—  CAIS  Tool  Writer 


CAIS  Environment  User 


Major  Areas  Of  Investigation 


IBM 


•  The  investigation  can  be  broken  down  into 
three  major  areas#  each  of  which  supports 
one  of  the  three  points  of  view  mentioned 
above: 


—  CATS  Interfaces 


-  CAIS  Tools 


Command  Line  Interpreter 


I 


Criteria  for  Evaluation 


IBM 


The  investigation  attempted  to  evaluate 
the  CAIS  in  each  oi  the  following 
criteria: 


Performance  /  Efficiency 


—  Usability 


1  -1  4-  »  • 


—  Feasibility 


Reliability 


1 


Completeness 


—  Ease  of  Implementation 

I 

I 


I 
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CAIS  Interface  Subset  Selection 


IBM 


Ml 


♦  The  CAIS  Subset  implemented  in  this 

investigation  was  chosen  with  two  basic 
criteria: 


—  Subset  should  be  robust  enough  to 

demonstrate  most  of  the  features  of  the 
CAIS  and  hence  be  a  reasonable 
representation  of  a  CAIS  environment. 


Subset  should  be  simple  enough  to  be 
implemented  in  a  reasonably  short 
amount  of  time . 


*  Some  tradeoffs  occurred  between  these  two 
criteria  in  reaching  the  final  CAIS 
subset. 
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CAIS  Interfaces  Supported 


IBM 


♦  The  CAIS  Subset  Implemented  in  this 

investigation  included  the  following  CAIS 
S pecif ication  interfaces : 

—  Node  Definitions 

—  Node  Management 

—  Nnrlg  A  ■h+’-r-i  Vn 

—  Relation  Attributes 

—  List  Utilities 

—  Form  Terminal 


Magnetic  T ape 


CAIS  Interfaces  Not  Supported 


IBM 


The  CAIS  Subset  implemented  in  this 
investigation  did  not  include  the 
following  CAIS  Specification  interfaces: 


Mandatory  and  Discretionary  Access 
Control 


Process  Spawning 


Input/Output  packages 


Page  and  Scroll  Terminals 


Interfaces  Added  to  CAIS 


IBM 


I 

I 

I 

I 

I 


I 

I 

E 

E 

i 

I 

I 

I 

1 

R 

I 


The  following  interfaces  were  added  to  or 
replaced  interfaces  of  the  CAIS 
Specification: 


—  Package  FILE-NODES 


-  Package  CAIS-ADDITIONAL-UTILITIES 
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CAIS  Tools 


IBM 


The  tools  used  in  the  investigation 

covered  a  wide  range  of  size  and 

functionality . 

—  Line  Counter  -  developed  for  this 

investigation 

—  Pretty  Printer  1  -  completely 
integrated 

—  Body  Stubher  -  completely 

integrated 

—  Pretty  Printer  2  -  partially  integrated 

—  Batch  Compiler  Submitter  -  partially 
integrated 

—  XEDIT  Editor  -  partially  integrated 

—  SPF  Editor  -  partially  integrated 


CAIS  Tools  Incremental  Development  Plan  IBM 


♦  Tools  were  integrated  into  the  CAIS  system 
in  four  stages  in  order  to  more  easily 
evaluate  the  usability  of  the  CAIS 
interfaces  from  the  point  of  view  of  the 
tool  writer. 

—  Level  1:  Tool  has  no  responsibility  for 
the  Node  Model.  ( No  Access  ) 

—  Level  2:  Tool  has  responsibility  of 
extracting  CMS  file  given  the 
appropriate  file  node/  but  not  of 
changing  the  node  model.  C  Read  Only ) 

—  Level  3:  Tool  has  responsibility  of 
extracting  CMS  file  given  the 
appropriate  file  node  and  of  creating 
any  new  nodes  as  the  result  of  the 
tools  operation.  C  Read/Write  given 
current  node ) 

—  Level  4:  Tool  responsible  for  all 
interactions  with  the  node  model 
( Read/Write ) 


Command  Line  Interpreter 


IBM 


« 


The  command  line  interpreter  was  developed 
tor  this  investigation  as  a  full-screen* 
menu- driven  user  interface  to  the  CAIS 
interfaces  and  tools.  The  CL I  screen  was 
composed  of  four  sections: 

—  Menu  section  -  contained  menus  of 
available  options . 


I 

I 

I 

I 

1 


Status  section  -  contained  information 
about  the  current  state  of  the  CAIS 
system. 


Display  section  -  contained  list  of 
current  user#  current  node*  and  primary 
relationships  from  current  node. 

Command  Line  -  used  for  user  input  of 
commands  and  information  needed  to 
process  menu  requests. 


§ 

I 

I 

I 

K 


A  separate  screen  could  be  activated  to 
display  all  of  the  information  regarding  a 
node*  including  attributes  and  associated 
CMS  file. 


I 

I 

I 


CAIS  Evaluation 


IBM 


The  iterative  development  approach  taken 
in  this  investigation  greatly  aided  in  the 
areas  of  testing  and  evaluation. 


The  CAIS  Subset  could  be  implemented 
and  tested  interactively  from  within 
the  command  line  interpreter*  rather 
than  with  short  test  programs  and  a 
dummy  CAIS  database. 


Relative  complexity  of  CAIS  interfaces 
could  be  more  readily  understood. 


Tools  could  be  integrated  into  the  CAIS 
environment  much  more  easily  by 
defining  levels  of  responsibility  for 
the  tools . 


The  CAIS  system  itself  could  be  used  as 
the  development  environment  of  the 
investigation. 


CAIS  Interfaces  Evaluation 


IBM 


♦  The  CAIS  Subset  was  initially  defined  to 
be  extremely  severe  in  order  to  examine 
the  performance  of  several  data 
structures. 


•  After  finalizing  the  data  structures  of 
the  node  model*  the  subset  was 
successively  enhanced  in  parallel  with  the 
command  line  interpreter  and  the  CAIS 
tools. 


♦ 


The  final  subset  was  robust  enough  to 
demonstrate  most  of  the  features  of  the 
CAIS. 


CAIS  Investigation  Code  Size 


IBM 


Description 

Lines  Of  Code 

CAIS  Interfaces 

3,  164 

CAIS  Tools 

2,  854 

Command  Line  Interp. 

5,  137 

Terminal  Interface 

4,  946 

1  U  i  AL 

16# 101 
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Abstract 

This  paper  describes  a  project  to  investigate  the  feasibility,  performance  and  utility  of 
a  CAIS  compliant  Ada  Programming  Support  Environment.  A  working  model  of  an 
environment  was  built,  with  a'command  language  interpreter  and  a  small  toolset.  Tools 
from  the  host  environment  have  heen  imported  and  made  to  behave  as  native  CAIS  tools. 
A  cumber  of  tools  have  :  ported  from  a  parallel  effort  by  a  MITRE  corporation  team 

with*  little  difficulty.  prototype  was  built  initially  for  correctness  and  enhanced 

later  for  performance  improvements.  The  performance  was  found  to  be  acceptable  as  a 
test  bed  for  development  of  prototype  tools  and  offered  hope  for  the  performance  of  a 
product-quality  implementation.  A  test  suite  for  compliance  with  the  standard  was 

—  ,.11..  iMolamaataX 
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1 .0  Introduction. 

The  Common  APSE  Interface  Set  (CAIS)  is 
designed  to  provide  a  common,  host- 
independent  model  for  Ada 1  programming 
development  tools  and  toolsets.  It  is 
currently  specified  in  a  Proposed  Military 
Standard  [11  with  a  rationale  document  [2] 
as  a  commentary  about  the  authors' 
intention*.  A  Reader's  Guide  [3]  gives  a 
more  readable  summary  of  the  CAIS.  These 
documents  have  been  produced  by  a  group 
called  the  KAPSE  Interface  Team  (KIT) 
with  support  from  Industry  and  Academia 
(KITIA).  The  proposed  standard  is 
intended  to  be  the  first  stage  towards  a 
more  ambitious  and  far-ranging  standard 
covering  aspects  such  as  distributed 
environments,  inter-tool  intei  faces, 
graphical  interfaces,  etc.  It  is  intended 
that  the  second  version  should  be  a 
compatible  superset  of  the 
current  version. 


I  Ada  is  a  registered  trademark  of  the 
U.S.  Department  of  Defense  (AJPO). 


This  paper  describes  a  prototype  of  a  CAIS 
environment,  implemented  on  a  host 
operating  system  and  designed  for 
correctness  rather  than  efficiency.  Some 
performance  figures  are  given  as  a  guide 
foi  future  designers  as  to  the  likely 
performance  of  a  usable,  product-quality 
CAiS-compatibie  environment. 

2.0  Overview  of  the  CAIS. 

The  CAIS  specification  describes  an 
operating  environment  which  is 
independent  of  the  underlying  system 
All  objects  in  the  system  are  mapped  to 
nodes.  Each  node  has  a  set  of  properties, 
or  attributes,  which  can  be  read  using 
CAIS  interfaces.  Some  of  the  attributes 
have  values  which  arc  properties  of  the 
node  and  cannot  be  changed  by  the  user. 
Others  have  values  which  can  only  change 
when  a  status  change  occurs.  The 
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attributes  described  so  far  are  called 
predefined  attributes.  Other  attributes 
have  user-defined  names  and  values  and 
can  be  changed  using  CAIS  interfaces. 

The  nodes  are  connected  by  relationships. 
Primary  relationships  join  the  nodes  to 
form  a  strict  tree,  rooted  in  a  system  node. 
The  removal  of  a  primary  relationship 
implies  the  removal  of  the  node  from  the 
model.  Secondary  relationships  can  point 
to  any  node  except  the  system  node,  which 
is  inaccessible  to  the  user. 

Relationships  are  labelled  by  relation 
names,  which  can  be  predefined  or  user- 
defined  in  the  same  way  as  attributes.  All 
relationships  have  keys.  Multiple 
relationships  with  the  same  relation  name 
are  distinguished  by  keys.  Relationships 
can  have  attributes  which  behave  exactly 
in  the  same  way  as  node  attributes. 

Nodes  are  used  to  describe  three  main 
kinds  of  objects.  These  are  files, 
structural  nodes  nnd  processes.  File 
nodes  consist  of  devices,  storage  files  and 
queues.  Queues  are  like  pipes  or 
mailboxes.  Structural  nodes  serve  as 
place-holders  for  relationships.  A 
structural  node  which  is  the  parent  of  file 
nodes  only  is  the  equivalent  of  a  directory 
in  a  host  system.  The  process  node 
normally  represents  the  execution  of  an 
Ada  program  which  may  consist  of  one  or 
more  Ada  tasks.  Processes  may  also  be 
written  in  other  languages. 

The  CAIS  environment  is  perceived  by 
APSE  tools  as  a  hierarchical  file  system 
with  process  trees  whether  the  host  system 
implements  these  features  or  not.  The 
environment  supports  a  number  of 
interesting  features  such  as  a  unified 
pathnaming  scheme  for  all  objects  in  the 
system  and  the  ability  to  form  mixed  trees 
of  processes  and  files.  The  intention  is  to 
facilitate  production  of  toolsets  consisting 
of  several  cooperating  processes  with 
flexible  communication  and  simple 
facilities  for  temporary  file  and  directory 
creation.  For  example,  when  a  process 
node  is  deleted,  its  offspring  must  also  be 


deleted.  Files  created  below  the  process 
in  the  tree  are  automatically  removed. 

Pathnames  are  formed  by  concatenating  the 
relation-key  sequences  to  traverse 
intermediate  nodes.  All  pathnames  used 
in  CAIS  service  calls  are  considered  to 
start  at  the  current  process  node.  For  the 
purposes  of  unique  identification,  a  node 
is  considered  to  have  a  primary  pathname, 
which  is  the  path  from  the  system  node  to 
that  node  using  primary  relationships 
only.  However,  primary  pathnames  are 
never  used  to  identify  nodes  to  CAIS 
services. 

The  CAIS  specification  identifies  a  static 
structure  of  top-level  nodes,  including 
device  codes,  user  nodes  and  role  nodes, 
which  cannot  be  added  to  or  removed  from 
within  the  CAIS  environment.  Device 
nodes  model  the  devices  supported  by  the 
environment.  User  nodes  are  structural 
nodes  that  become  the  top  of  the  user's 
local  tree  when  the  environment  is 
entered.  P.olc  codes  define  iccets  control 
groups.  The  implementation  can  structure 
a  top-level  tree  with  any  combination  of 
file  and  structural  nodes. 

When  a  user  enters  the  environment  (by  an 
implementation  defined  method),  a  user 
node  is  identified  as  the  current  user  and 
a  top-level  process  node  is  generated 
which  is  an  offspring  of  the  current  user 
code  via  a  primary  Job  relationship.  This 
process  node  is  a  control  program  that 
defines  the  environment’s  appearance  to 
the  user.  Normally,  a  command  language 
interpreter  would  perform  this  function, 
bur  this  need  not  be  so.  If  the  top-level 
process  node  exits  or  aborts,  the  user 
exits  from  the  environment  and  the  whole 
current  process  tree  is  terminated.  From 
the  top-level  process  node,  other  process 
codes  can  be  initiated  in  wait  or  no-wait 
mode  as  offspring  processes.  These 
processes,  in  turn,  can  initiate  other 
processes.  Any  process  can  generate  an 
independent  process  tree  off  the  current 
user  node  or  off  any  other  accessible  user 
node  using  the  create  Job  service.  The  new 
process  tree  is  not  terminated  when  the 
current  user  logs  out. 
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The  CAIS  provides  code  management 

facilities  for  general  node  and  pathname 

manipulation.  Other  areas  of  functionality 

are: 

1)  a  set  of  I/O  packages  modelled  closely 
on  the  Ada  packages  to  facilitate 
conversion  of  Ada  tools  to  the  CAIS 
standard. 

2)  an  access  control  model  based  on 
current  DoD  concepts  [4]. 

3)  a  virtual  terminal  interface  modelled 
on  industry  standard  terminal 
functionality. 

4)  a  standard  magnetic  tape  interface 
based  on  the  ANSI  standard  [5]. 

5)  an  import-export  package  to  transport 
files  from  and  to  the  host  system. 

6)  a  standard  list  format  based  on  a 
restricted  form  of  the  Ada  aggregate 
format.  This  is  used  to  pass  complex 
information  from  the  user  to  the  C.AIS 
and  to  pass  parameters  between 
processes. 

7)  a  model  of  Queue  handling  designed  to 
Simplify  the  construction  of  Command 
Language  Interpreters. 

8)  a  process  control  model  designed  to  be 
simple  enough  to  be  implemented  on 
most  systems  currently  in  existence. 

30Goals  of  the  prototype 
Implementation. 

It  was  felt  that  the  CAIS  needed  working 

implementations  because:- 

a)  the  successive  versions  of  the  CAIS 
specification  had  received  much 
criticism  on  the  grounds  of 
performauce,  unimplemeatability  and 
unusability . 

b)  a  working  model  would  enable 
potential  users  to  evaluate,  train  or 
plan  for  the  future  and  would 


stimulate  interest  in  the  unique 
features  of  the  CAIS. 

c)  we  and  other  tool  manufacturers  would 
be  able  to  generate  working  CAIS 
compliant  tools  in  readiness  for  the 
release  of  production  quality  CAIS 
environments. 

d)  the  access  control  model  in  the  CAIS  is 
complex  and  rich  in  function.  There 
was  a  need  for  self-education  by 
implementing  a  literally  correct 
prototype  before  going  on  to  implement 
an  efficient  analog. 

The  immediate  goals  of  our  prototype 
were:- 

a)  Correctness. 

b)  Portability.  There  was  to  be  as  little 
use  of  OS-unique  features  as  possible. 
The  prototype  was  to  be  coded  in  Ada. 

c)  Re-usability.  It  was  hoped  that  large 
pans  of  the  code  would  bs  independent 
of  the  underlying  model. 

d)  Education.  The  project  provided 
training,  on  the  CAIS  and  in  Ada 
programming 

c)  Timeliness.  A  literal  implementation 
of  the  model  of  the  nodes  and  their 
access  mechanisms  would  produce 
useful  results  far  faster  than  attempts 
to  design  an  efficient,  quality  product 
from  the  start. 

Implementation  of  the  Magneticjape  and 
Formjerminal  packages  was  postponed, 
since  these  were  the  least  essential 
packages  for  our  environment. 

4.0  Prototype  Implementation. 

4.1  Design  strategy. 

The  design  was  undertaken  using  the 
structured  design  methods  of  Constantine 
and  Yourdan  [6].  It  was  found  that  the 
production  of  structure  charts  could  not 
proceed  beyond  the  first  few  levels 


without  a  clear  idea  of  how  the  node 
database  was  to  be  implemented.  Having 
settled  on  a  basic  approach  and  layout,  we 
were  able  to  specify  a  package  for  access 
to  the  nodes.  It  was  then  possible  to 
complete  the  structured  design  of  the  node 
management  packages.  As  this  proceeded, 
we  were  able  to  refine  the  node  access 
package  interface.  We  were  then  able  to 
complete  the  structured  design  of  the 
latter  package. 

4.2  Hirdvsre  and  Software 
Environments. 

The  software  was  implemented  on  a  Gould 
Powernode2  9080  which  is  a  tightly- 
coupled  dual  processor.  32-bit 

superminicomputer  with  a  performance 
rating  of  around  10  Mips.  The  software  is 
capable  of  running  on  any  of  the  Gould 
Powernode  60xx  and  90xx  series 
computers. 

The  design  of  the  CAIS  prototype  was 
targeted  to  both  Gould's  UNIX3 
implementation,  UTX/322,  and  to  its 
proprietary  Real-Time  Operating  5ystem, 
MPX-323  .  It  was  implemented  using  the 
ICC4  Ada  translator  (version  3.1),  an 
unvahdated  translator  from  Ada  to  the  "C" 
language  It  was  intended  to  port  the  code 
to  Gould's  validated  compiler  when  this 
became  available  on  the  two  target 
operating  systems.  The  software  was 
demonstrated  on  UTX/32  using  the  ICC  3.1 
translator  in  April  1986.  The  port  to  the 
Gould  compiler  on  UTX/32  followed  the 
latter  demonstration. 

4.3  Implementation  of  the  Nodes. 

The  original  design  consideration  of  OS 
independence  forced  us  to  map  'die  nodes 
onto  disk  files.  Each  component  of  the 
node  (relations,  attributes  and  contents)  is 
kept  in  a  separate  file.  A  further  file  was 

2  Powernode,  UTX/32  and  MPX-32  are 
trademarks  of  Gould  Inc. 

3  UNIX  is  a  trademark  of  AT&T  Bell 
Laboratories. 

4  Irvine  Compiler  Corporation. 


designated  the  nodt  private  status  to  hold 
the  private  description  of  the  node  and 
information  about  its  open  status.  The  use 
of  separate  files  was  designed  to  reduce 
contention  when  parts  of  the  nodes  were 
locked,  since  only  one  of  the  target  hosts 
supported  record  locking. 

The  nodes  were  to  be  held  in  a  single  host 
OS  directory  is  the  first  implementation 
and  access  to  them  was  to  be  limited  to 
processes  logging  in  through  the  CAIS 
login  facility.  The  node  filename  formed 
the  unique  node  pointer  which  is  needed  to 
track  the  node  during  its  lifetime. 
Relationships  point  to  the  code  even  when 
it  is  renamed  within  the  CALS. 

4.4  Implemeutatlou  of  the  Node 
Handles. 

The  Node  handle,  which  is  returned  when 
a  node  is  opened,  cannot  be  implemented 
exactly  as  specified  in  the  Proposed  MIL- 
STD-CAIS  This  is  because  tbs  node  type 
is  limited  private  to  a  single  package, 
Node_definitions.  Its  contents  art  not 
only  hidden  from  the  user  but  also  from 
the  rest  of  the  CAIS  packages.  The  option 
to  move  it  to  an  enclosing  CAIS  package  so 
that  the  type  becomes  visible  to  all  sub- 
packages  but  not  to  the  user  packages  was 
rejected  because  the  ICC  translator,  at  that 
time,  did  not  support  separate 
compilation.  The  size  of  the  CAIS  would 
have  made  program  development  too  time- 
consuming.  Instead  an  internal  package 
was  used  to  perform  the  unchecked 
conversion  from  ocu€_type  iau  access 
type)  to  node  record  pointer.  Functions 
were  provided  to  access  and  manipulate 
the  handles  from  within  the  CAIS. 

4.5  Access  to  tbe  Nodes, 

The  two  main  approaches  to  the 
implementation  of  uode  access  were:- 

a)  to  implement  one  or  more  servers  to 
mediate  access  requests  to  -the  nodes  so 
that  transactions  could  be  serialized. 
The  server’s  error  recovery  could 
always  guarantee  the  consistency  of 
the  node  model. 
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b)  to  use  direct  locking  on  the  parts  of 
the  file  nodes  and  to  perform  Ada  or 
Host  I/O  directly  on  the  node  pans. 

The  lack  of  a  common  message  passing 
mechanism  for  both  Host  OS's  tended  to 
point  away  from  option  (a).  Also  a  common 
server  could  become  a  performance 
bottleneck  in  any  simple  implementation 
on  a  multi-processor  system. 

Option  (b)  was  selected  for  implementation 
but  the  following  problems  were  foreseen:- 

1)  Every  tool  in  the  environment  would  be 
forced  to  cany  all  the  CAIS  package 
code,  a  large  overhead  in  disk  and 
memory  space  which  could  only  be 
alleviated  by  the  use  of  shared 
libraries. 

2)  The  possibility  of  deadlocked 
processes  would  be  increased  by 
haviug  many  tools  locking  parts  of  the 
nodes  a:  raudom. 

2)  Exit  processing  had  to  be  performed  by 
an  outside  entity  so  that  nodes  could 
be  closed  and  the  database  returned  to 
normality  when  aborts  occurred. 

4)  The  method  lacked  robustness  since 
there  was  no  protected  database 
manager  with  inherent  recovery 
facilities.  System  crashes  or  process 
aborts  could  leave  the  database  in  an 
inconsistent  state. 

5)  There  was  no  protection  against 
concurrent  use  of  the  tame  node  handle 
by  separate  tasks  in  a  single  process. 
Serialized  transactions  would  at  least 
have  reduced  some  of  the  damage 
possible  if  a  tool  used  a  node  handle  in 
such  an  erroneous  fashion. 

The  following  precautions  against  items  1 
to  5  were  ukea:- 

a)  Locking  of  more  than  one  pari  of  a  node 
by  a  single  process  was  done  according 
to  strict  code  of  practice  rules 
designed  to  allow  processes  to  back  off 


and  retry  if  they  could  not  lock  all 
parts  required  in  one  request. 

b)  All  opens  and  closes  of  nodes  are 
reported  to  a  job  server  whose 
functions  include  closing  nodes  left 
open  after  an  inadvertent  exit  or  abort 
of  a  process.  The  job  server  is 
described  later. 

c)  An  extra  file,  the  semaphore  file,  was 
added  to  process  nodes  to  coordinate 
suspension,  resumption,  abortion  and 
deletion  without  fear  of  becoming 
deadlocked.  A  semaphore  package 
implemented  functions  for  set,  reset, 
test  and  test-aad-set  so  that  the 
semaphore  functionality  could  be  re¬ 
implemented  in  shared  memory  if  this 
became  available  in  the  future. 

d)  Automatic  node  checking  on  the  lines 
of  UNIX  file  checking  was  to  be 
implemented  incrementally. 

e)  The  prototype  would  ignore  the 
dangers  of  user  misuse  of  node  handies 
described  in  item  5. 

I/O  to  the  nodes  used  Ada  I/O  of  variant 
records  to  implement  linked  list 
structures  for  relation  and  attribute  node 
pans. 

So  far  deadlocking  of  processes  and 
robustness  have  not  been  an  issue.  The 
node  checking  and  repairing  facility  has 
been  designed  but  only  a  subset  has  been 
implemented. 

4.6  Access  synchronization. 

A?  a  higher  level  than  the  locking  of 
’individual  node  parts,  the  CAIS  requires 
that  separate  processes  contend  for  access 
to  nodes  using  a  host-independent  access 
synchronization  model.  Each  process 
opening  a  node  states  for  which  intents  the 
node  is  to  be  opened.  There  are  26  intents, 
based  on  combinations  of  exclusive  or 
shared,  read,  write  or  append,  and  access 
to  all  or  part  of  the  node.  When  a 
requested  intent  is  incompatible  with 
currently  open  intents  on  the  node,  the 
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requestor  must  wait  (with  a  time  limit) 
until  the  node  is  closed.  The  waiting 
process  will  then  be  released  with  an  open 
node  handle. 

Tasks  in  a  process  can  contend  for  a  node 
with  other  processes,  with  other  tasks  in 
the  same  process  or,  incorrectly,  with 
themselves.  In  the  absence  of  a  common 
synchronization  method  for  all  these 
cases,  a  package  based  on  events  with 
unique  identifiers  was  specified.  Events 
can  be  signalled  or  waited  on  with  a  time 
limit.  Waiting  processes  place  the  e  nt 
identifier  into  a  wait  queue  in  the  node 
private  status,  report  to  the  job  server  and 
wait  on  the  event.  Whenever  a  process 
closes  the  node,  it  scans  the  wait  list  for 
compatible  requests,  signals  all  such 
events  and  removes  the  entries. 

The  event  services  were  to  be  re¬ 
implemented  in  the  most  efficient  way 
available  on  the  host  system. 

4.7  Access  control. 

Although  it  would  have  been  possible  to 
implement  a  CAIS  environment  without 
access  control,  it  was  considered  essential 
to  include  it  in  our  prototype  in  order  to 
gain  a  good  understanding  of  its  features. 
The  CAIS  specification  follows  the  DoD 
Document  on  Evaluation  criteria  for 
Trusted  Computer  Systems  [4],  referred  to 
as  the  TCSEC.  Both  Discretionary  and 
Mandatory  access  control  are  specified. 
Since  ueither  of  our  tatgetted  hosts 
implemented  Mandatory  access  control,  it 
was  feh  that  i, implementation  of  such  a 
feature  without  the  ua<  crlying  support 
from  a  protected  domain  was  probably 
futile  aisd  misleading.  Neither  of  the  Host 
OS's  in  their  present  form  can  aspire 
beyond  the  C2  level,  which  is  the  highest 
level  in  the  TCSEC  categories  with  no 
mandatory  access  control. 

Discretionary  access  control  was 
implemented  by  imposing  it  as  an  extra 
restriction  on  existing  host  controls.  This 
means  that  nodes  would,  in  a  final  system, 
be  inaccessible  to  all  but  the  System 
Administrator  or  to  processes  logged  in 


through  the  CAIS  login  facility.  In  our 
current  working  system,  nodes  are 
accessed  using  group  rights. 

Our  implementation  followed  these 
guidelines:- 

a)  It  was  done  literally,  as  described  in 
the  specification,  using  secondary 
relationships  and  their  GRANT 
attributes. 

b)  All  top-level  user  nodes  are  roles, 
with  access  relations  to  themselves, 
granting  full  access  to  adopting 
processes. 

c)  The  top-level  process,  generated  when 
a  user  logs  in  to  the  environment,  is 
automatically  given  an  adopted,role 
relation  to  its  user  node. 

d)  Top-level  nodes  and  their  access 
relations  are  created  offline.  When  a 
process  node  is  created,  it  is  given  a 
relationship  to  each  top-level  node  or 
role  node  to  which  access  was 
specified.  The  relations  are  USER  to 
user  nodes,  DEVICE  to  all  device  nodes 
and  ALLOWACCESS  to  all  other 
accessible  nodes.  The  ACCESS  relation 
runs  from  the  object  :o  th:  user  node. 
This,  by  itself,  does  not  provide  a 
path  to  the  object. 

e)  When  a  process  node  is  created,  it  is 
provided  with  an  adcpted_role 
relationship  to  its  executable  file 
node. 

Figure  1  shows  a  node  tree  with  one  user 
and  a  role  node.  This  role  node  holds  a 
tool  which  has  been  invoked  by  the  top- 
level  process  uode.  Only  access  control 
and  primary  relations  ate  shown.  The 
access  relation  frum  the  user  node  to  itself 
and  the  adopted_role  relation  from  the  cli 
to  its  own  executable  file  node  are  not 
shown.  Some  experiences  with  access 
control  are  described  later. 

4.8  Process  control. 
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The  implementation  of  process  control 
marked  the  greatest  divergence  from  the 
goal  of  portability.  The  MPX-32  system 
does  not  support  process  trees,  whereas 
the  UTX'32  system  supports  UNIX  process 
trees  which  are  similar  to  the  CAIS  trees. 
Therefore,  UNIX  facilities  were  used  to 
ease  the  implementation  of  process  control 
on  that  system. 

The  package  was  implemented  using  two 
demons.  These  are  UNIX  processes 
communicating  through  sockets  with  the 
actual  CAIS  processes.  The  main  process 
control  demon  is  the  job  demon.  This 
controls  all  processes  generated  in  a 
single  job  tree.  There  is  also  a  resume* 
suspend-abort  demon  (the  RSA  demon). 

4.8.1  The  JOB  demon. 

The  user  logs  into  the  environment  by 
starting  a  login  process  from  the  UNIX 
shell.  The  login  process  sets  off  a  job 
demon,  having  established  a  root  process 
node  and  its  relations  under  the  user  node. 
The  job  demon  is  passed  parameters  (using 
the  host  OS  mechanism)  which  indicate  the 
node  pointer  for  the  top-level  process  node 
and  the  file  node  for  its  executable  image. 
The  job  demon  then  initiates  the  top-level 
process  and  waits  for  communication  via 
its  socket. 

Processes  communicate  with  the  job  demon 
when:* 

a)  a  node  is  opened,  closed  or  the  open 
intents  are  changed. 

b)  another  process  is  to  be  invoked  or 
spawned. 

c)  an  offspring  exits. 

The  job  demon  detects  exits  via  the  signal 
generated  by  UNIX  when  a  child  process 
exits  or  aborts.  It  makes  sure  tha:  nodes 
are  not  left  open  or  with  pending  open 
requests  in  their  private  status. 

The  create_job  service  makes  the  new 
process  tree  into  a  direct  offspring  of  the 
current  process,  not  of  the  current  job 


demon.  This  prevents  the  new  job  demon 
from  being  entered  in  the  old  job  demon  s 
list  of  process  nodes.  In  this  way,  if  the 
user  logs  out,  the  old  job  demon  removes 
all  offspring  processes  but  does  not 
remove  the  job  demon  created  by  the 
createjob  service.  Note  that  this  job 
demon  it  left  parentless  in  the  host  system 
*  this  is  possible  in  UNIX  but  not  in  the 
CAIS.  The  new  job  demon  controls  its  tree 
is  the  same  way  ca  the  other  job  demons. 

It  was  decided  that  the  CAIS  was  deficient 
in  sot  specifying  a  DELETE_JOF  icrvice  to 
remove  completed  batch  jobs.  The  KIT 
opinion,  at  that  time,  was  that  such  job 
trees  should  be  cleaned  up  outside  the 
CAIS  in  the  same  way  as  the  original  login 
job  tree.  A  DELETER  OB  service  was  added 
pending  settlement  of  this  issue. 

When  a  job  demon  has  no  offspring,  it 
closes  all  open  nodes  and  then  exits.  If 
the  login  process  is  waiting  on  the  job 
demon,  it  awakens  and  prompts  for  a  user 
name. 

The  contrasting  UNIX  and  CAIS  process 
trees  are  shown  in  fig.  3. 

4.8.2  The  RSA  demon. 

The  CAIS  allows  processes  to  resume, 
suspend  or  abort  any  process  to  whose 
node  the  current  process  node  has  the 
necessary  access  rights.  Since  the  UNIX 
host  does  not  allow  unprivileged  processes 
to  do  these  things  to  processes  with  a 
different  user  identifier,  this  is  done 
through  an  intermediary,  the  RSA  demon. 
There  is  only  a  need  for  one  such  demon 
per  host  system  even  if  a  number  of 
separate  node  models  are  being  used 
simultaneously.  The  CAIS  process  control 
code  verifies  the  CAIS  rights  and  converts 
from  a  node  pointer  to  a  host  process 
identifier  (held  in  the  victim  process  node 
private  status).  This  identifier  is  sent, 
with  the  change  of  status  request,  to  the 
demon  which  performs  the  action. 

4  9  I/O  and  terminals. 
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The  similarity  between  the  CA1S  I/O  and 
the  Ada  I/O  packages  leads  one  to  believe 
that  an  implementation  of  CAIS  I/O  on  top 
of  the  Ada  I/O  packages  might  be  feasible. 
However,  certain  differences  in  approach 
between  the  packages  indicate  that 
difficulties  would  arise  if  this  course  were 
taken.  In  particular,  I/O  to  terminals  has 
facilities  such  as  prompts,  intercepted 
characters  and  function  keys,  which  made 
it  necessary  to  deal  with  terminals 
independently  at  many  points  within  the 
code. 


The  CAIS  I/O  packages  were  implemented 
down  to  a  low-ieve!  set  of  subprograms 
below  which  the  CAIS  I/O  would  be  host- 
dependent.  Fortunately,  most  of  the  I/O 
facilities  available  on  the  UTX/32  system 
have  equivalents  on  the  MPX-32  host. 


Problems  with  the  use  of  file  handles  and 
node  handles  in  the  proposed  MIL-STD- 
CAIS  have  been  well  publicized.  Re- 
implementation  with  the  scheme  recently 
proposed  [9]  should  make  our 
implementation  more  elegant,  since  our 
keep  pcsetcrs  vV.iStauMtu^  to 


the  node  handle  used  to  open  the  file  even 
when  the  node  handle  is  closed.  This 
ensures  that  open  path  information  is 
available  at  all  times.  In  the  new  scheme, 
it  will  not  be  possible  to  close  the  node 
without  also  closing  the  file,  so  the  CAIS 
access  synchronization  cannot  be 
subverted. 


Terminal  I/O  needs  a  number  of  unique 
features  from  the  host  OS.  The  Get 
subprograms  must  be  capable  of 
proceeding  with  execution  if  no  characters 
are  available  in  input  buffers.  The  OS 
supported  features  for  line  editing  must 
be  by-passed  so  that  intercepted 
characters  and  function  keys  can  be 
specified  as  described.  This  means  that 
raw  I/O  (binary  I/O)  must  be  used  in  the 
UTX/32  system. 


against  a  user's  mixing  textjo  and 
scroll/pagejerminal  services  on  the  same 
terminal.  Since  textjo  used  processed 
I/O  and  the  terminal  packages  used  raw 
I/O,  the  packages  did  not  mix  well.  For  a 
first  implementation,  this  was  tolerable 
so  long  as  the  user  took  care  to  use  only 
support  functions  of  text_io  with  the 
terminal  packages.  Support  functions  such 
as  »et_input,  set_output,  open  and  close 
are  generally  compatible  in  that  they  do 
tittle  or  no  I/O  to  the  terminal.  At  a  later 
date,  it  is  intended  tn  make  textjo  for 
terminals  use  raw  I/O  and  perform  its  own 
line  editing. 

In  order  to  map  available  terminals  onto 
the  CAIS  virtual  terminal  models,  the  UNIX 
termcap  (terminal  capabilities  file) 
feature  was  adapted  for  a  specialized  use. 
The  CAIS  list  format  (List_utilities 
package)  was  found  to  be  ideal  for 
specifying  such  a  file  in  order  to  simplify 
parsing  of  the  user’s  terminal  description. 
Termcap  commands  were  reduced  to  those 
necessary  to  support  the  CAIS  facilities, 
and  several  were  added  to  implement 
features  directly. 

The  six  standard  file  nodes  required  by 
any  CAIS  process  were  opened  during 
Textjo  package  elaboration.  This  was 
found  to  be  a  considerable  overhead  for 
process  start-up.  Deferment  of  the 
opening  of  the  nodes  until  first  use  was 
felt  to  be  unwise  since  a  process  could 
then  find  itself  locked  out  of  its 
current_output  a  long  time  after 
successfully  opening  and  using 
current  Jnput.  It  was  found  that  the 
elaboration  overhead  could  be  reduced 
considerably  by  working  below  the 
Node_management  interfaces  from  T«xt_io. 
This  is  mainly  due  to  the  fact  that  all  six 
standard  relations  usually  pciot  to  the 
same  code  and  that  all  six  opens  can  be 
done  at  the  same  time  as  the  first  open  on 
Standardjnput. 


The  implementation  dealt  with  textjo  for 
terminals  as  though  they  were  files  using 
the  host  OS's  line-editing  and  device 
independence  facilities.  This  was  a 
mistake,  since  there  is  no  protection 


4.10  Maintenance  Facilities. 

A  utility  generates  the  System  node 
together  with  the  static  structure  of  top- 
level  nodes  which  cannot  be  manipulated 
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from  within  the  environment.  This  utility 
is  capable  of  generating  multiple  node 
models  in  the  same  host  system  with  the 
restriction  that  no  more  than  one  node 
model  can  occupy  a  single  host  directory. 
Low-level  node_m*nagemeot  routines  are 
used  to  build  and  modify  nodes  without 
regard  to  access  synchronization. 

A  node  mending  utility  was  produced, 
which  is  capable  of  accepting  a  node 
primary  name  and  removing  outstanding 
open  intentions  from  the  private  status. 
Repair  facilities  for  the  relation  and 
attribute  files  have  not  yet  been  found 
necessary. 

The  prototype  was  integrated  and  tested 
without  the  benefit  of  a  source  level 
debugger,  so  switchable  trace  code  was 
built  in  to  the  Ada  source.  All  exceptions 
can  be  sent  to  standard  output  through  a 
switchable  reporting  routine  that  outputs 
the  exception  name,  the  current 
subprogram  name  and  a  brief  reason.  The 
debug  trace  and  exception  reporting  is 
switchable  using  flags  in  the  UNIX 
environment  which  are  program-testable. 

Other  tools  found  necessary  for 
maintenance  were  dump  tools  for  relation 
and  attribute  parts  of  the  node. 

5.0  A  CAIS  Test  Suite. 

The  strategy  of  prototyping  implies  that  at 
least  two  versions  of  the  software  arr 
planned.  In  reality,  it  was  foreseen  that 
even  the  prototype  would  go  through 
several  versions  as  performance  was 
enhanced  and  errors  were  corrected.  A 
test  suite  was  seen  as  the  best  way  to 
verify  that  successive  implementations 
were  still  correct.  A  test  manager  was 
specified  and  designed,  which  would  run 
as  a  CAIS  process.  This  test  manager 
would  interpret  scripts  or  accept 
commands  interactively,  run  tests,  log 
results  and  format  them. 

A  set  of  approximately  700  tests  were 
originally  specified.  Of  these,  time  and 
manpower  allowed  the  implementation  of 
95.  The  large  size  of  CAIS  processes  in 


our  implementation  quickly  caused  a  disk 
space  problem.  This  was  solved, 
temporarily,  by  linking  the  tests  by 
package  into  test  drivers.  These  drivers 
accepted  a  CAIS  process  parameter  from 
the  parent  test  manager  and  branched  to 
the  test  specified  by  that  parameter. 

All  tests  had  to  be  self-contained  and 
built  their  own  structures  in  a  working 
node  directory  as  required.  The  test 
manager  cleaned  them  up  after  the  test 
completed. 

6.0  Command  Language  Interpreter 
and  Tools. 


The  first  Command  Language  Interpreter 
produced  during  development  was  a 
simple,  interactive,  exerciser  for  the 
Node_management  and  Process_control 
packages. 

A  more  formal  Command  Language 
Interpreter  was  later  produced,  which 
accepts  commands  based  on  Ada  language 
features.  For  example,  a  tool  invocation 
for  a  copy  tool  resembles  an  Ada 
subroutine  call:- 

copy  (from->pathnamel,  to->pathname2) 
or 

copy  (pathnamel,  pathname2) 

where  both  alternative  sets  of  parameters 
are  in  the  CAIS  List  format  and  can  be 
passed  more  or  less  intact  to  the  tool.  The 
CLI  allows  minor  relaxations  from  the 
strict  List  format.  For  example,  quotes  (“) 
around  pathnames  and  outer  parentheses 
around  the  parameters  may  be  omitted. 

Most  CLI  features  have  tended  to  parallel 
in  Ada  those  supplied  by  the  UNIX  C- 
shell,  which  supports  a  Job  Control 
Language  similar  to  the  "C"  language.  So 
far,  the  CLI  has  been  implemented 
entirely  with  CAIS  subprogram  calls  and 
so  is,  theoretically,  a  portable  tool. 
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A  toolset  was  developed,  mainly  of  small 
database  management  tools  such  as  Create, 
Copy,  Rename,  Import,  etc.  for  the 
display  and  maintenance  of  the  nodes.  A 
consistent  toolset  parameter  interface  was 
specified  and  a  small  Ada  package  of  tool¬ 
building  subprograms  was  built. 

A  group  of  UNIX  tools  were  brought  into 
the  CAIS  environment  as  'alien"  tools. 
This  was  done  in  anticipation  of  a  demand 
for  sophisticated  tools  during  the  early 
lifetime  of  the  CAIS.  The  vi  editor,  the 
UNIX  print  program  and  the  ICC  Ada 
compiler  and  linker  were  imported.  Of 
these,  only  the  print  program  was  fully 
functional.  A  CAIS  tool  was  written  in  Ada 
to  interpret  the  parameters  from  the  CLI, 
convert  CAIS  pathnames  to  host  pathnames 
(by  subverting  CAIS  interfaces)  and  then 
activate  the  alien  tool  as  an  offspring 
process  in  the  host's  process  tree.  The 
process  node  for  the  CAIS  tool  took  the 
place  of  the  actual  too)  in  the  CAIS  process 
tree. 

The  vi  iooi  was  fuocnonai  except  that 
reads  and  writes  from  within  the  editor 
used  host  pathnames.  In  a  real  tool,  these 
commands  would  have  to  be  suppressed  or 
modified.  The  Ada  compiler  and  linker 
were  imported  for  demonstration  purposes 
only,  since  the  whole  library  management 
file  set  was  external  to  the  CAIS  and  only 
the  source  and  executable  files  were  held 
in  the  CAIS  environment. 


7.0  Experiences  with  the  CAIS. 

7.1  Access  control. 

When  our  first  working  multi-user 
environments  were  created,  the  large 
number  of  access  relations  became  an 
immediate  problem.  The  desire  to  share 
access  to  tools  led  to  the  introduction  of 
the  group  roles  provided  by  the  CAIS 
specification. 

Access  to  tools  in  a  user's  own  user  tree  is 
controlled  when  the  user  creates  the  tool. 
Access  control  lists  can  specify  the  access 


rights  to  be  granted  to  the  current  user, 
other  users  and  to  group  roles. 

Sharing  tools  by  granting  access  to  other 
users  or  by  making  the  tool  executable  file 
nodes  into  group  roles  rapidly  becomes  a 
painful  overhead  in  any  system  as  the 
number  of  users  increases.  Sharable  tools 
are  better  placed  as  offspring  of  group 
roles  as  shown  in  Figure  1.  Read  access  to 
the  group  allows  the  user  to  traverse  to  the 
group.  Read  and  execute  access  from  the 
tool  to  the  group  gives  adopters  of  the 
group  the  right  to  execute  the  tool.  To  add 
tools  to  the  group,  a  user  needs 
append_relationships  access  to  the  group 

Access  to  other  user  trees  as  an  automatic 
right  is  awkward,  since  membership  of  a 
common  group  gives  access  to  nodes  off  the 
higher  members  of  the  group  tree.  In 
order  to  work  down  such  a  tree  it  is 
accessary  to  use  the  secondary 
potential_member  relation  to  invert  the 
tree.  Each  user  wishing  to  access  another 
user’s  nodes  must  become  a 
potential  merober  of  that  ujcr,  so  mutual 
sharing  generates  a  web  of 

potentialjnember  relationships. 

If  more  than  two  users  wish  to  share  trees, 
it  is  more  efficient  to  make  the 
potential_member  relationships  from  the 
common  group  roles  into  two-way 
relationships.  This  is  shown  in  Figure  2. 
This  means  that  for  every  relationship 
which  makes  a  user  into  a  potential 
member  of  the  group,  another  relationship 
makes  the  group  a  potential  member  of  the 
user.  In  this  way,  each  user  can  access 
another  user's  nodes  by  a  two  stage 
adoption  (adoption  is  not  a  high  overhead 
for  a  process).  First,  the  group  is  adopted 
using  the  allow_&ccess  relation.  Next,  the 
other  user  is  adopted  by  traversing  the 
downward  potential_member  relation,  an 
action  validated  by  tbe  upward 

poteatial_member  relation.  Using 

reciprocal  po te n t i a  I  _  m e m be r 
relationships,  the  number'  of  such 

relationships  in  a  group  of  n  users  is 
reduced  from  l0  2«.  The  situation  in 
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Figure  2  allows  two  users  to  adopt  each 
others  user  role. 

Access  control  is  as  area  of  the  CAIS 
which  is  easily  described  using 
relationships.  However,  the  costs  would 
rapidly  become  prohibitive  even  with 
group  access  rights  unless  real 
environments  used  compressed 
representations  of  the  model.  Static  access 
control  structures  can  easily  be  cached 
within  each  process  to  increase 
performance. 

7.2  Tool  building. 

The  KIT  members  have  correctly  predicted 
that  CAiS  implementations  will  tend  to 
generate  their  own  higher  level  CAIS 
packages  for  tool-building. 

Examples  of  subprograms  found  useful  to 
our  implementation  a re:- 

user_key-  obtain  the  key  of  the 

current  user  (the  username). 

make_access_list  -  build  a  default 

access  control  list  for  node 
creation. 

replace_wild_cards  -  replace  wild  cards 
in  a  pathname  so  that  standard 
CAIS  facilities  such  as  pathjtey 

will  accept  the  path 

remove_relation_and_key  -  split  off  the 
last  relation  and  key  from  a 

pathname  ignoring  wild  cards. 

Considerable  support  was  needed  for  the 
Iterator  services,  which  have  often  been 
criticised  for  their  minimal  functionality 
and  apparent  inefficiency.  We  have  made 
proposals  for  extra  iterator  services,  but 
it  is  likely  that  no  iterator  interface  will 
find  complete  acceptance  in  the  user 
community. 

7.3  Tool  portability. 

A  set  of  tools  were  supplied  by  the  Mitre 
corporation  from  their  prototype  CAIS 
implementation  [7J.  These  were  ported 


onto  our  environment  as  an  experiment  in 
portability.  Their  group  of  node 
managemeut  tools  ported  directly  on  to  our 
environment  with  no  changes  except  for 
'with*  and  'use"  Ada  package  statements. 

The  other  two  tools  supplied  were  an 
interactive  menu  manager  called  Video  and 
a  line  oriented  text  editor  called  Aled. 
Both  programs  were  originally  obtained 
from  the  Ada  repository.  The  Aled  tool 
used  ScrolMerminal  interfaces  and  the 
Video  tool  used  Page_terminal. 
Unfortunately,  at  that  time,  the  Mitre 
implementation  of  these  packages  was  only 
partial  and  it  was  necessary  to  modify 
both  tools  to  handle  the  different  approach 
to  input  of  control  characters  in  the  full 
implementation.  The  tools  ported  easily 
once  the  input  sections  were  recoded  to 
use  function  keys. 

8.0  Performance. 

The  first  demonstrable  version  of  the 
prototype  was  available  in  December  1985 
and  was,  as  expected,  very  slow.  Log  in  to 
the  environment  took  an  average  of  20 
seconds  and  tool  invocation  took  an  average 
of  25  seconds 

A  short  performance  enhancement  project 
of  3  months  was  undertaken,  in  order  to 
have  a  publicly  acceptable  demonstration 
by  April  1986.  The  areas  of  enhancement 
were:- 

a)  Templates  were  used  foi  process  node 
relations  and  attributes  files  so  thai 
simple  file  copies  could  be  used  to 
generate  the  process  nodes.  The 
templates  were  built  by  the  Generation 
utility  used  to  build  the  static  top- 
level  node  framework. 

b)  Each  process  node  has  a  group  of  pre¬ 
defined  relations  which  can  only  be 
modified  by  calls  to  CAIS  interfaces. 
The  node  pointers  for  these  relations 
were  cached  sc  that  the  open  services 
no  longer  needed  to  search  the 
relations  file  to  access  the  nodes. 
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c)  The  open  and  spawn  services  are  the 
points  at  which  any  inefficiency  in 
the  implementation  is  perceived.  Much 
of  spawn's  time  is  spent  in  the  open 
service,  therefore  close  attention  to 
this  service  is  the  key  to  increased 
efficiency. 

1)  traversal  of  node  relationships  can 
be  improved  by  use  of  low-level 
interfaces  rather  thau  formally 
opening  each  intermediate  node  tor 
read_relationships  and  closing  the 
same  node  later.  If  lock-out 
occurs,  the  traversal  code  backs  up 
to  call  the  full  CAIS  open  service 
so  that  access  synchronization  to 
the  intermediate  node  works 
correctly. 

2)  access  control  potentially  involves 
searches  of  trees  of  roles. 
Considerable  care  must  be  taken  in 
the  implementation  of  these 
searches.  The  role  trees  are  static 
since  PERM  ANENT_  MEMBER 
relationship;  cannot  be 
manipulated  by  users.  Therefore 
cached  or  reformatted  access 
control  information  should  be 
used. 

d)  Analysis  of  the  quantity  of  I/O 
performed  on  node  parts  showed 
immediate  and  spectacular  areas  for 
improvement. 

The  version  demonstrated,  in  April  1986, 
to  members  of  the  KIT/KITIA  and  to  other 
interested  parties  showed  a  fourfold 
increase  in  performance  for  the  two 
measures,  entry  into  the  environment  and 
tool  invocation.  The  times  are  compared  in 
table  1  below.  Spawning  time  for  a  tool  is 
the  time  between  a  call  to  spawn  and  the 
completion  of  the  new  process  elaboration. 
The  exit  time  is  the  lime  from  the  last 
Ada  statement  to  the  end  of 
await_process_completion  in  the  parent 
process. 

Version  1.0  is  the  December  1985  version 
and  version  1.2  is  Ute  April  1986  version. 


All  times  were  measured  on  a  stand-alone 
Gould  9080  system.  The  software  was 
built  using  the  ICC  3.1  Ada  translator 
running  on  UTX/32  (the  UNIX  host). 


Table  1.  Sample  performance 
measurements  for  the  Gould  CAIS 
prototype. 


Measurement  Version  1.0 

Version  1.2 

Entry  into  the 

18.0s 

4.2s 

environment. 

Spawning  a 

25.5s 

6.9s 

tool. 

Exiting  from 

11.9s 

1.3s 

a  tool. 


9.0  Size. 

Table  2  shows  a  list  of  CAIS  package  sizes 
expressed  as  number  of  lines  of  code 
(whole  line  comments  excluded),  number 
of  statements  and  number  of  bytes  of 

- J  _  * _ .  -  .1  1 »  i 

i V*  vuuv  kcuciaicu  UJ  uic  /\ua 

translator  on  a  Gould  system.  The  number 
of  statements  was  based  on  a  count  of 
semicolons  not  found  in  strings  or 
comments.  It  is  intended  to  show  the 
relative  complexity  of  coding  of  the 
packages. 

Notice  that  the  process  control  line  count 
includes  the  code  for  the  job  and  RSA 
demons,  while  the  byte  count  does  not, 
$>nce  these  are  in  separate  executable 
files  of  no  great  size. 

The  CAIS,  implemented  as  a  son-shared 
library,  is  a  considerable  overhead  for 
any  real  APSE  environment.  For  every  tool 
in  the  environment,  more  than  1  Megabyte 
of  disk  space  must  be  reserved.  Also, 
small  memory  configurations  suffer 
considerable  degradation  because  of 
increased  swapping  as  more  users  enter 
the  environment.  Our  development 
machine  was  configured  with  16  Megabytes 
of  memory,  but  most  users  at  this  time  do 
not  have  such  luxury. 
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Tabic  2  Lice  counts  and  storage  for  CAIS 
packages. 


MHHffi 

•gircr 

•mini* 

1 

nrm 

1.232 

*> 

msm 

i  mu  i  r  i  — 

EFfcn, 

1.671 

mi 

rut  si 

Fit*  I/O 

BUI 

4 .764 

■EDI 

ii  tnws 

msm 

Ortct  to 

mira 

MM 

J  to_contfo» 

»rm 

- 

mna 

1 

■KTTTWT^H^H 

* 

IgyjLjjj 

ILi  TngYTTpT— 

man 

302 

1.1 

■nxm 

WES 

2.092 

7.7 

■rang 

lOJ _ 1 

mm 

1,729 

mm* 

HIM 

Hm 

■  ■■ 

IHHHH 

■H 

ran 

—nan 

—j  ' 

ran 

■mem 

■IW 

mu-ii 

6.4 

asrn 

767 

HEOH 

■fTTCT 

5.0 

Fpiinf  r#4i!b*»a 
Otbuf 

rtUtlfMI 

2,199 

1 .449 

D 

19.949 

2.972 

19.979 

1.4 

0.2 

l.> 

CAIS  API  (Ml 

iSUi 

20.491 

iim 

1.009.399 

147 

II  ill  11111111 

IH 

IHI 

1 

■i/inu 

li  i  ii  mm\ 

ran 

ra 

■did 

lumim— 

arm 

inxEi 

I0D3HB1 

\mxtm 

Included  in  rode_m«nao*m«nl  total 
line  count  include*  demon*,  byte  count  doe*  not. 


The  use  of  a  node  server  to  perform  all 
access  to  the  code  model  would  reduce  the 
amount  of  code  held  in  each  tool  as  would 
the  introduction  of  shared  Ada  libraries. 
Ideally,  such  shared  libraries  would  be 
placed  in  some  kind  of  protected  domain  so 
as  to  improve  the  credibility  of  the  CAIS 
as  a  Trusted  Computing  Base.  It  has  been 
pointed  out  [8]  that  such  shared  libraries 
would  introduce  minor  technical  problems 
in  the  area  of  generic  packages  in  the 
CAIS. 

10. 0  Future  Flans. 

The  prototype  source  has  been  offered  for 
public  distribution  at  a  nominal  price  for 
evaluation,  tool-building  and  for 
education.  Other  software  such  as  our  Test 
suite,  toolsets  and  CLI  are  regarded  as 
proprietary  at  this  time. 

The  immediate  plans  for  this  project  are  to 
implement  the  remaining  packages  to 
attain  as  near  to  100%  functionality  as  is 
practicable.  The  remaining  packages  are 
Magnetic_tape  and  Form_terminal. 

It  is  intended  that  the  environment  be 
ported  onto  a  Secure  Unix  product 


produced  by  this  company.  This  version  of 
UNIX  is  currently  being  evaluated  for 
compliance  with  the  Cl  level  as  specified 
in  the  TCSEC  [4], 

1 1 .0  Couclusions. 

We  feel  that  the  following  conclusions  can 
be  drawn  from  the  project:- 

1)  the  CAIS  is  implementable  on  a  UNIX 
host.  We  are  reasonably  confident  that 
our  design  could  be  ported  to  our  own 
Real-Time  Operating  System. 

2)  the  performance  overheads  are  not 

prohibitive.  The  times  quoted  are 

stand-alone  on  a  powerful  machine, 
but  it  should  be  noted  that  this 
prototype  was  designed  with  only 
small  regard  for  ultimate  efficiency. 
Careful  design,  using  prototyping 
experience,  should  enable  us  and 

others  to  produce  an  environment  with 
an  acceptable  user  response. 

3)  the  CAIS  does  provide  usable  features. 
Much  criticism  of  the  specification  has 
stated  that  interfaces  are  too  primitive 
for  tool-builders.  We  have  found  it 
possible  to  build  useful  higher-level 
services  using  the  primitive  interfaces 
in  the  specification. 

4)  the  access  control  model,  while 

complex,  does  appear  to  provide  the 
features  required  to  implement  a  full 
discretionary  access  control  model  to 
cuiTent  DoD  requirements. 

5)  the  prototype  is  a  useful  tool  for 

further  investigation  of  the 
implications  of  the  CAIS  specification 
and  it  is  stable  enough  to  build 
working  tools  and  toolsets  in 
anticipation  cf  future  production 

environments.  This  should,  in  theory, 
reduce  the  lead-time  before  such 
environments  support  a  ..  worthwhile 
body  of  applications  software. 

It  is  hoped  that  some  of  the  data  in  this 
paper  are  of  some  use  to  other  potential 
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itnplementers  in  their  own  estimates  of 
time  and  man-power  required. 
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Reported  results  to  KIT/KITIA  (January  16,  1985  — *  Frank  Belz) 


ASE  CAIS  Prototyping  Accomplishments  (ASE)  TVtwY 
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1.  Introduction 

The  Common  Ada  Programming  Support 
Environment  (apse)  Interface  Set2  (cais)  is 
a  set  of  interlaces,  defined  in  Ada3 *,  which 
promote  the  transportability  of  software 
development  tools,  and  which  enhance  the 
ability  to  move  project  development  data¬ 
bases  between  cais  implementations.  These 
interfaces  support  large  scale  programming 
projects,  such  as  are  encountered  in  mission 
critic j1  Defense  Department  computer  sys¬ 
tems  work. 

This  paper  examines  cais  as  it  relates  to  the 
System  V  Interface  Definition,  3VID  (and 
Unix  4  as  a  particular  implementation  of 
sviD),  The  paper  begns  by  exploring  why 
the  cais  effort  exists,  its  goals,  and  the 
solutions  it  attempts  to  achieve  which  arc 
not  in  todays  implementations  of  “vamlla 
Unix  ’.  Next,  the  paper  examines  the  anti¬ 
cipated  user  community  and  why  it  is 

»  A  ^  *  Ifl  TL*  r>,  « i  /in.»  I  !«{••• 
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picscnt  in  ihc  current  version2  and  the  func¬ 
tions  left  for  later  versions  arc  identified. 
Two  means  of  iinplcnicu'ing  cvis-Iikc  func¬ 
tionality  on  host  systems  (such  as  UNIX)  arc 
identified;  present  iinplementalions  of  cais 
arc  categorized  and  discussed.  Finally,  a 
comparison  is  made  between  cais  and  the 
European  Portable  Common  1  ool  Interface 
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(PCTE)  project,  possibly  one  of  the  most 
ambitious  and  CAis-like  UNIX  extensions 
under  way. 

2.  Goals  of  CAIS 

2.1  Tool  Transportability  and  Interoperabil¬ 
ity 

The  primary  goal  of  CAJS  is  to  solve  a  per¬ 
ceived  problem  in  DoD:  a  lack  of  tool  tran¬ 
sportability  and  interoperability  facilities  (J) 
among  defense  system  support  contractors, 
(2)  between  contractors  and  the  Govern¬ 
ment,  and  (3)  between  Government  enritics 
themselves.  (The  Unix  aficionado  might 
feel  that  he  has  had  the  answer  to  these 
sorts  of  problems  for  years;  he  must  be 
reminded,  however,  that  neither  the 
Government  nor  its  contractors  have  histori¬ 
cally  been  big  fans  of  unix  systems,  mostly 
because  of  the  inability  to  support  program¬ 
ming  in  the  very  large  on  what  were  histon- 

««ll«>  •'•"knll  nh>4*i4  IkkMVf  «•••»«.,**»  \ 
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The  Government  is  expected  to  spend,  this 
year,  over  SI 3.54  Billion  on  mission-critical 
computer  software5  (not  including  business 
and  accounting  applications).  At  typical 
rates  of  expenditures,  over  126,000  software 
people  work  on  over  500  defense  projects 
(supported  by  many  other  categoiics  of 
non-sofiwinc  labor).  Several  of  the  projects 
include  software  deliveries  of  the  tens  of 
millions  of  loutcc  lines.  This  code  is 
expecud  to  be  maintained  for  the  lengthy 
iifctluic  of  military  equipment;  thus  the  abil¬ 
ity  to  have  many  tcama  work  on  parts  of  the 
job.  at  differing  support  sites  eve  the 
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system  lifecycle,  is  important.  (Large  pro¬ 
jects  are  often  developed  by  several  organi¬ 
zations  and  mamtained  by  others.  This 
entails  a  variety  of  computers  and  operating 
systems,  and  moving  the  project 
database/'filesystcm.) 

The  cais  itself  focuses  on  the  support  of 
software  tools,  in  development  environ¬ 
ments.  It  is  not  intended  to  be  a  real-time 
or  applications-supportive  system,  though 
several  have  suggested  that  cais  facilities 
may  apply  to  non-development  applications 
too. 

The  cais  currently  defines  an  advanced 
filesystem  (database),  a  process  model,  a 
security  model,  some  device  control,  and 
some  access  synchronization.  I  he  difficult 
issue  of  data  interoperabtlit >  is  a  deferred 
item  for  the  cais  authors  to  tacklj. 

2.2  Defined  in  Ada 

The  CA  15  is  defined  in  Adn,  tird  is  intended 
to  support  tools  written  in  the  Ada  language. 
Mar.y  of  its  interfaces  appear  in  an  Ada 
style,  vising  strong  typing,  overloaded  pro¬ 
cedure  call  selection,  and  Ada-like  packag¬ 
ing  There  was  no  attempt  or  concern  to 
support  previous  languages  when  cais  was 
first  defined;  however,  current  interest  in 
compatibility  with  ether  languages  may 
influence  cais  implementations  to  support 
pricr-gcncration  languages. 

1  ^  IT  I - 1  r - —  ADCf 

nui’t.u  iivnu  ni  ^  v y net: jx t 

In  the  late  1970’s,  Ada  environment 
research  developed  the  concept  of  a 
development  environment  architecture 
based  on  a  layered  model.  Called  the  Ada 
Programming  Support  Environment  (aJ'SK), 
this  model  is  shown  in  figure  1. 

The  core  of  the  Ai’SE  is  the  Kernel  apue 
(KA)’Sfc).  It’s  purpose  was  considered  novel, 
to  encapsulate  dilTciing  host  muchirte  and 
operating  system  capabilities  into  kernels 
which  all  had  3  common  intc'faee  to  hipnc 
level  tools  and  u’-cr  programs.  7 he  kapse 
included  such  general  rmteio  sei vices  a?,  file 
management,  process  contiol,  device  con¬ 
trol.  ar.d  hardware  resource  control. 

Sui'ounding  (he  kaS’SE  in  the  original 
models,  is  the  Msimuli  AIMS  (MAJ’gK).  a 
layer  with  "coding”  tools  loci',  ks  editors, 

3  -t,W 


compilers,  linkers  and  command  inter¬ 
preters.  Current  thought  focuses  more  on 
the  need  for  an  apse  to  support  the  entire 
life  cycle  of  software.  This  extends  the  sup- 
por  t  environment  beyond  coding  tools,  with 
such  facilities  as  requirements  analysis  and 
design  support  tt  ;t  suppon,  management 
support,  and  the  li  e.  However,  in  the  ori¬ 
ginal  model,  these  t  -atures  were  considered 
project  unique  tools  and  relegated  to  the 
APSE  layer  of  the  model. 

The  important  contribution  of  this  mode)  is 
the  idea  that  a  kernel  (kapse)  can  be 
defined  with  standardized  interfaces  so  that 
low  level  tools  (c.g.,  language  compilers)  and 
high  level  tools  (c.x.,  project  suppon  and 
configuration  management)  can  be  indepen¬ 
dent  of  specific  underlying  hardware  and 
host  operating  system  software. 

2.4  Influenced  by  UNIX 

Cais  has  been  strongly  influenced  by  Unix 
Many  defense  projects  axe  sul1  hosted  on 
fiat  lilcsysicms,  such  ns  IBM’s  370  series 
operating  systems.  The  cais  designers  felt 
the  need  to  provide  more  advanced  filesys¬ 
tem  support.  Unix  was  seen  ns  a  model  for 
filesystem  ideas  and  for  process  control. 
Though  lirtx  was  considered  nunc 
advanced  than  many  defense  project 
environments  in  use,  it  too  was  perceived  to 
have  shot  teeming!  in  the  area  of  supporting 
large  projects.  This  lead  to  the  more  gen¬ 
eral  node  mod*!  in  CAUt. 
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F;tting  uNix-like  process  concepts  into  Ada 
was  not  straightforward.  Ada  implies  a 
tasking  rendezvous  model,  which  permits 
only  synchronous  parallelisms,  and  then 
only  when  the  parallel  parts  are  all  compiled 
and  linked  together.  Unix,  on  the  other 
hand,  permit  asynchronous  parallelisms, 
connected  by  pipes  and  other  vehicles, 
where  each  process  lives  In  its  own  address 
space  an  1  protected  trorr.  the  other. 
Resolving  these  philosophical  differences 
was  not  easy. 

2.5  Why  Ada  alone  (without  CAIS)  is  not 
enough 

With  the  C  language,  a  portion  of  unit  (C 
library)  is  required  to  augment  the  machine 
independent  portion  of  C  with  sufficient 
functions  to  be  useful  in  an  operating 
environment.  Ada  must  also  be  augmented 
with  functions,  at  leas’,  in  the  host  system 
environment,  because  it  too  lacks  tool  sup¬ 
port  functions  (of  the  sort  provided  by 
unix).  Two  key  features  absent  from  Ada 
arc  the  underlying  model  of  the  system  level 
data,  and  the  ability  to  support  dynamic 
binding  (process  control).  The  cais  defines 
a  nod':  modal  (file  system  model)  and  a 
dynamically  bound  model  for  multiple 
independent  programs  to  inter-react  as 
processes  in  real  time.  Cais  augments  Ada 
with  some  of  the  nibt  ax  y- level )  functions 
found  in  unix.  Cais  docs  not  define  ah  the 
tool  interfaces  found  in  unix.  and  it  docs 
not  define  any  accompanying  utility  pro- 
grants,  user  shtils,  mist  the  sort  of  functions 
expected  of  UNIX  distributions. 

5.  Who  will  u««  C'AliS 

The  tAi.'i  will  appeal  to  supplim,  custo¬ 
mer.,,  and  piojects  beset  with  the 
Government’s  problem,:  namely,  supporting 
multiple  teams  of ’.oftware  'ool  usns  on  dif¬ 
ferent  host  pioduci*;,  over  ».  lengthy 
loft  war*  system  lifecycle,  it  is  unlikely  to 
appeal  to  developed  of  dred  v  singlc-usci 
products  (such  as  smgk-u.t>  J’eisotial  Com¬ 
putet  jofi wo. e),  developers  u<  p’.ydueu 
which  require  hardwuic  loci'-h;  in  ordei  to 
protect  ihrir  market,  oi  bc'c.’rpcis  ol 
clusoU-iucbitcuYUic  products  who  it'd  case 
of  inijgiuiior.  ol  foitigu  viftv  aie  prout.’ti 
eiodcs  their  r.imktt  position. 


3.1  Tools  and  tool  builders 

Most  tool  builders  today  strive  to  support  a 
broad  bast  of  customers  on  a  broad  class  of 
hardware.  Indeed,  the  popularity  of  UNIX 
implementations  :s  due  to  this  phenomenon. 
Cai?  carries  the  unix  notion  of  indepen¬ 
dence  further,  into  the  Ada  domain,  and 
into  a  domain  of  a  more  sophisticated  data¬ 
base  capable  of  supporting  programming  in 
the  large.  Cais  may  initially  appeal  pri¬ 
marily  to  Government  contractors,  and  to 
tool  builders  supplying  that  marketplace. 
However,  the  near  equivalence  of  non-Ada 
efforts,  such  as  the  European  Esprit 
Program’s  PCTE  project,  supported  by 
several  svid  implementations  for  the  indus¬ 
trial  and  commercial  (non-Government) 
market,  lends  credence  to  the  need  for 
CAis-like  system  functionality. 

3.2  Project  environments 

large  programming  environments  need 
strong  configuration  m  nagement,  the  abil¬ 
ity  to  support  hetr’-ogeneous  hosts  with  the 
same  tool  base,  and  the  need  to  support 
their  tool  base  over  a  lengthy  time  period. 
During  the  maintenance  of  the  software,  one 
is  likely  to  sec  four  or  five  h3rdv  are  genera¬ 
tions,  and  expected  rcprocurcmcnts  of  sup¬ 
port  equipment.  Cais  makes  Ada  tools 
independent  of  hardware  and  underlying 
host  OS  changes. 

4.  r/uai’a  ixre  rreaoot  CAIS 

4.1  Node  mood  including  processes 

Unix  supports  its  users  with  a  stnctly 
hierarchical  filesystem.  For  example  figure 
1  shows  u  typical  usc.-oi iciued  bicttucl  y 


rtfo*"  a.  V««i  ||.,WW  l,y  <>'  tl!»* 


Most  iuiplemtnuiiun  i  y<  Unix  use  the 

d.iectu*  i  StiU'.fiMC  to  support  UiCis.  I  igrc 
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2  shows  two  users,  mary  and  joe ,  each  with 
their  independent  hierarchy  o'.  Files, 
independent  of  the  work  assignments  and 
project  considerations.  For  example,  joe 
has  a  project  directory,  with  a  source  direc¬ 
tory  for  three  programs  (and  presumably 
also  has  binary  and  test  program  directories 
for  the  same).  Another  hypothetical  direc¬ 
tory  might  include  documentation.  Whether 
mary  is  working  on  the  same  project  or  not, 
the  files  under  her  control  would  be  in  her 
own  directory  hierarchy. 

Cais  supports  building  secondary  networks 
of  relationships,  such  as  pioject  directories 
with  logical  connection  paths.  Shown  as 
curved  arcs  in  the.  follow  ing  figure,  are  a  set 
of  links  from  logical  components  to  an  own¬ 
ing  project  (regardless  oi  v/hich  user  owns 
them).  Relationships  can  cover  a  number  of 
logical  connections,  such,  as  r.rojcct  owner¬ 
ships,  project  version  relationships,  and  the 
like,  (in  a  far  more  complex  manner  than  in 
figure  3). 


f  3,  N«t»orC  of  rtlMioiuhijn 

While  present  UNIX  distributions  do  urn 
support  non-biciarchica!  linkages  or  inp.r 
filesystem  linkages,  some  sviu  extensions, 
such  as  rcTis,  ptovidc  the  same  type  ul  sup- 
poil.  In  general,  the  model  uvidcrlyr.g  C/ria 
is  one  of  a  sc;  of  entities  (c.g.,  tools,  users, 
lilej)  and  their  iw  a  relationship;  These 
may  be  depicted  ii  o  diitcud  graph  of 
nodes  and  edges,  where  the  nodes  repincm 
file,  device,  dircctoiy,  or  process  oojects; 
and  die  edge:,  denote  iclit/onshipt. 

A  database  ichci/.u  loi  the  node,  model  is 
shown  in  figure  4. 


7ifur«4.  #eh*m»  for  CAIS  nod*  mod*! 

An  important  attribute  of  the  cats  is  that 
processes  arc  pan  of  the  node  model.  (This 
is  similar  to  an  enhancement  to  the  experi¬ 
mental  Eighth  Edition  of  UNIX  which  has 
processes  in  the  filesystem  namespace.) 
With  processes  as  named  nodes  in  cais,  one 
can  have  relationships  between  processes, 
between  processes  and  file/dircctory  nodes, 
and  between  processes  and  nodes  for  the 
implementation  of  security  access  models. 

4.2  Terminal  and  Device  control 

Cais  defines  input/output  for  the  nodes 
(filesystem),  as  well  as  for  terminals  anil 
tape  devices.  Terminal  ate  supported  as 
character  imaging  devices  at  present.  Cais 
provides  support  for  three  typer  of  tens'll- 
nals:  scrolling  tennnais,  page-mode  termi¬ 
nals,  and  fui ins-mode  terminals.  Scrolling 
terminals  are  basically  teletype -like  devices 
which  have  no  cursor  control.  Page  termi¬ 
nals  have  full  sctccn  capabilities  and  arc 
equivalent  to  the  common  anm  type  of  ter¬ 
minal  fee,.,  %H00).  Forms  icrmina.s  display 
fixed  field  menus,  arid  receive  channel  to 
data  fields,  similar  to  some  of  the  1UM  .32 Tx 
style  devices 

Only  rudimentary  device  coouol  has  been 
provided.  Fur  tapes,  the  opeintiom  pro¬ 
vided  allow  the  CAlj  to  support  Hie  creation 
foi  transport  between  cais  how  uystc.tu. 
*1  he  intola'  cs  handle  lubcled  tnd  utilabcled 
tnpc.r. 

4J  Security  MoiIbI 

CAlri  piovidM  twi  kinds  of  security  v  cess 
Conti  oL  tnandiCory  Mid  durr nonary.  Man- 
da’oty  cou'.ioh,  eg -lenient  to  the  convcn 
tiona.1  hictjtchy  of  bNCi./j*iriu>. 
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CONFIDENTIAL,  SECRET,  and  TOP  SECRET, 
identify  the  operations  of  reading,  writing, 
and  reading/writing  by  a  classifying  node. 
Discretionary  controls,  equivalent  to  the 
UNIX  style  of  user/group/other 
read/write/cxecutc  bits,  limit  the  authorized 
access  of  process  nodes  (executing  pro¬ 
grams)  {subjects),  to  other  nodes  (e.g„  file 
nodes)  as  objects.  Unlike  undc,  access  is 
not  controlled  by  storing  a  pattern  of  bits 
and  maintaining  user  and  group  id’s. 
Instead  certain  relationships  are  defined  to 
other  nodes  to  deteiroinc  a  node’s  role. 
Typical  operations  such  as  set-uscr-id  are 
replaced  by  ?.  specific  process  having  secon¬ 
dary  relationships  such  as  one  known  as 
ADOPTED-ROLE. 

5.  What’s  Not  in  present  CAIS 

Cats  docs  provide  many  of  the  equivalent 
functions  of  svid’s  system  calls  (UNIX 
manual  chapter  two);  namely,  typical 
kernel- level  system  services.  In  addition, 
seme  cf  the  library  fuuc’ions  (Unix  manual 
chapter  three)  are  provided. 

Cajs  docs  not  ar  present  provide  a  number 
of  deferred  items.  These  include: 

«  Database  Schema  and  Entity  Typing 
methodology.  Currently  deferred  is 
decision  whether  or  not  the  cajs  should 
enforce  a  particular  typing  methodology 
and  what  types  of  CAIS  interfaces  should 
be  available,  to  support  »t.  ypmg  cuuiu 
range  from  simple  schema  representation 
of  allowed  relationships  for  classes  of 
node  linkages  to  a  comprehensive  con¬ 
trol  of  process  access  to  nodc3  depend¬ 
ing  on  rules. 

•  Distribution.  The  existing  definition  of 
cais  is  intended  to  be  Lniplcrnc  otabic  on 
a  distributed  set  of  processors,  but  in  a 
manner  which  is  transparent  to  caw 
interfaces. 

*  Advanced.  User  lntcrfnr.es.  The  cun  cm 
cats  docs  not  piovidc  interfaces  for  tire 
establishment  of  windows  or  bit  mapped 
displays. 

«  1  mu -tool  interlaces.  The  current  cajs 
docs  not  proscribe  the  foruau  uf  data 
between  UKilj,  not  does  it  provide  Jny 
inter  oi  cr  ability  dau  inter  laces.  The 


equivalent  of  svid  file  formats  (unix 
manual  chapter  5)  has  not  been  deter¬ 
mined. 

•  Configuration  management  and  archiv¬ 
ing.  The  current  cais  interfaces  support 
tools  which  implement  configuration 
management  or  archiving,  but  there  is  no 
proscribed  underlying  model  for  such 
tools  to  follow.  In  a  sense  this  is  similar 
to  the  current  situation  with  Unix  imple¬ 
mentations,  where  sites  individually 
determine  tools  and  procedures  to  follow 
in  tliis  regard.  There  is  an  effort  under 
way  to  expand  CAIS  to  include  version 
control. 

0.  How  to  implement  CAIS 

There  are  Two  ways  to  provide  implementa¬ 
tions  of  the  cais:  a  native  implementation 
within  a  kernel  (where  the  Cais  is  or 
becomes  pari:  of  the  host  operating  system), 
or  a  piggyback,  implementation  vn  iop  of  a 
host  operating  system  or  kernel.  There  are 
prototypical  examples  of  both  forms  of 
implementation  at  present. 

6.1  Kernel  implementation 

The  only  project  under  way  which  is  in  this 
category  is  the  European  implementations 
of  pcte,  as  modifications  to  umx  System 
V.2  (sec  section  6.3).  The  implementations 
currently  do  not  support  Ada  or  Ada  inter¬ 
faces;  however,  the  “C”  interfaces  provided 
wiil  be  shown  to  map  cleanly  into  CALS  ser¬ 
vice::  A  cais  implementation  on  top  of 
PCTL  would  use  Ada  library  routine t,  which 
translate  the  Ada  interfaces  of  cais  into 
undci lying  ICTK  kernel  services.  This 
would  not  be  called  piggyback  because  the 
low  level  services  in  the  kernel  provide  a 
significant  portion  of  the  functionality  of  the 
node  model,  without  relying  on  superirn 
posed  user -state  sof  tware  to  implement  it. 

6.2  Piggyback  lmpUui«nuUuu 

A  piggyback  implementation  of  the  cais 
might  be  schematically  shown  as  in  ligire  5. 
When  implemented  on  ft  Unix  cnviiuvmcrK. 
the  CAlfl  implementation  exists  primarily  as 
user -suite  coding,  g<  ir.rally  without  any 
char  tjes  to  the  undo  lying  kc.‘ncl  Either 
shared  common  processes  can  be  used  tor 
the  cais  implementation  or  purely  user 
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linked  coding.  Two  firms  implementing 
cais  by  this  technique  are  Mitre  and  Gould, 


Figur*  6.  Piggybtck  CAIS  implementation 

6J  PCTE 

Pcte  will  be  introduced  and  compared  to 
cais  because  of  two  relevant  points,  it 
exists  2s  svid  extensions,  and  it  provides  a 
significant  part  of  cais  functionality  in  a 
kernel-levci  implementation. 

Pcte  is  both  an  interface  set  and  a  proto¬ 
type  implementation. 

i  As  an  interface  set,  fcte  exists  as  a  set 
of  man  pages0,  which  describe  the  PCTE 
node  model,  transaction  processing 
model,  distributed  processing  interlaces, 
and  user  interface  primitives  (windowing 
and  locator  device  support). 

•  As  a  prototype  implementation,  pcte 
exists  as  a  Unix  System  V  kernel  exten¬ 
sion,  scheduled  for  test  in  198(5.  A 
second  implementation,  known  as 
Emcraude,  seeks  to  provide  a  production 
quality  version.  The  pcte  prototype  is 
part  of  the  EEC  Esprit  Program,  and 
Erncraude  is  a  French  national  project. 

Aii  additional  implementation  of  PCTE  in 
Ada  is  scheduled  to  be  performed  by 
Olivetti  as  a  piggyback-styled  implemen¬ 
tation  intended  to  be  portable  oil  a 
variety  of  hosts  and  processors. 

6.J.1  IjVJD  Extension* 

Pcte  implements  a  physically  disnibuted 
database  of  objects,  with  a  logically 

0.  /'  0*7  7'  A  /or  #  i’vritM*  7Y«W 

Funr.liolkcJ  8|>*Uflcl4to!w ,  ThUU 
Ldliiuu.  JJUU,  (FiAjjit)  »t  ti.,  108(1. 


distributed  kernel.  Figure  6  shows  how 
three  workstations  might  share  a  logical  dis¬ 
tributed  kemcL  In  this  example  each  works¬ 
tation  has  some  portion  of  the  database 
objects  physically  resident  in  its  own 
hardware,  under  the  control  of  its  own  local 
kernel,  but  has  transparent  access  to  all 
other  objects  of  the  system-wide  (homo¬ 
geneous)  database. 

In  Figure  6,  Ul  represents  the  User  Inter¬ 
face  software  function  of  a  workstation; 
objects  represent  database  files  and  attri¬ 
butes  stored  locally  on  a  workstation,  and 
IKC  prot.  represents  the  inter-kernel  com¬ 
munications  protocol. 


diauibuiiOi* 


K«ni«l  wid  DfU*  Caoo 

Pcte  extends  itvm  V.2  in  four  logical  areas. 

These  3i  c 

1.  Baste  Mechanism.  The  basic  mechan¬ 
isms'  logical  components  arc  execution 
prinL lives,  communications  primitives, 
and  imcr-proccss  communication 
P’ iiuit.'vcs.  The  execution  primitives, 
fm  pi occss  and  context  management, 
opciatc  on  a  transparently  distributed 
cuviiomucnt  of  heterogeneous  woiks- 
tauons.  The  communication  primi¬ 
tives  piovidc  the  trauiparem  access  to 
distributed  objects  (replacing  aviu 
filesystem  primitives).  Tlie  inter- 
pi  occss  communication  primitives 
implement  piping,  messages,  and 
iharcd  memoiy  on  a  tr&uspaicmly  dis 
tributed  environment.  One  can  su.i  a 
pipeline,  where  pipe  processes  arc 
physically  scpaia'.cd  on  Ulficicnt 
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workstations,  and  their  objects  again 
on  different  workstations. 

2.  Object  Management  System  (CMS). 
The  CMS  implements  pcte’s 
equivalent  of  the  cais  node  model.  It 
is  an  Entity-  Relationship  model,  based 
on  a  schema  with  typed  nodes,  attri¬ 
butes.  and  relationships  (but  without 
type-checking  on  process  usage  of  o?«ts 
objects).  The  Schema  is  partitionablc, 
so  that  logical  views  supportive  of  user 
or  project  needs  can  be  implemented, 
and  control  of  object  relationships  can 
be  regulated.  (E.g.,  an  object  program 
could  have  a  derived-from  relationship 
to  a  source  progiam  but  not  a  mailbox 
file.)  The  oms  replaces  the  entire  typi¬ 
cal  svid  filesystem,  providing  compati¬ 
ble  interfaces  so  that  binary  code 
capability'  is  retained  for  old  programs 
ported  to  the  pcte  implementation.  It 
also  adds  support  for  the  node  model, 
relationships  and  attribute  mainte¬ 
nance,  and  transparent  distribution  of 
objects. 

The  pcte  oms  also  provides  con¬ 
current  access  synchronization,  both 
in  the  form  of  simple  locking  and  tran¬ 
saction  comum/abort  support  (eg., 
rollback  of  object,  relationship,  and 
attribute  status  to  state  prior  (o  com¬ 
mit  action  if  a  transaction  sequence  is 
aborted). 

3.  UrAnbtUion.  J'CVK  supports  fully  tran¬ 
sparent  process  and  object  distribu¬ 
tion.  It  doC3  this  with  only  two  primi¬ 
tives  in  the  entire  pcte  definition 
which  explicitly  reference  network, 
nodes  (foi  explicit  starting  of  a  process 
on  a  specific  workstation  in  the  case 
where  several  may  qualify  for  execut¬ 
ing  a  certain  process). 

4.  Lhcr  Interface.  The  User  Interface 
functions  of  pcte  implement  a  over¬ 
lapped  windowing  system,  using 
mousc-like  locator  devices,  on  bit¬ 
mapped  terminals.  The  physical  ter  - 
mmaJ  inter  faces,  in  one  implement;! 
lion,  with  a  User  Agent  function, 
which  interface:  to  applicuiruus  ngcuu 
fur  each  iu:mmg  process,  I’lutcsscs 
can  either  have  an  active  window  on 


the  screen  or  be  iconized  (replaced  by 
a  symbol).  Th«  Applications  Agent 
provides  a  virtual  terminal  for  the 
application,  so  that  user-state  programs 
need  net  deal  with  window  manage¬ 
ment. 

6.3.2  PCTE  and  CAIS 

Pcte  is  similar  to  cais  in  a  number  of  areas: 

•  The  node  models  arc  nearly  identical. 

•  The  relationship  models  are  very  similar. 

•  Attributes  are  handled  in  a  similar 
manner,  though  schema  typing  in  pcte 
causes  some  practical  attribute  handling 
differences  from  cajs  implementations 
without  schema  support  and  attribute 
typing. 

•  The  Process  model  can  be  installed  in  a 
similar  way.  Though  pcte  implements 
processes  in  die  manner  of  System  V.2 
(e.g.,  processes  are  identified  by  identifi¬ 
cation  numbers  which  arc  integers), 
diere  is  precedence  in  experimental 
implementations  of  Unix  Eighth  Edition 
to  make  Processes  pan  of  the  filesystem 
“name  space”.  Pcte  could  cither  inherit 
the  mechanism  of  that  Unix  version,  or 
it  could  use  a  library  routine  (outside  of 
the  kernel)  to  implement  processes  as 
special  types  of  nodes. 

Ada  tasks,  both  on  pcte  and  on  conven¬ 
tional  svid  implementations,  art 
expected  to  be  implemented  by  compiler 
libraries  which  place  all  linked  tasks  for 
a  given  Ada  program  as  a  single  (or  set 
of  SVID  processes.  In  general,  it  is 
doubtful  that  separate  task:  can  be 
represented  by  independent  processes; 
thus  the  process  model  of  cais  can  be 
made  to  correspond  diicclly  to  the  pro¬ 
cess  model  cL  rcTt  aod  svid. 

»  Finally,  Adu  implemented  I/U  should  be 
Uni  same  on  both  l'CTE  and  cais  imple¬ 
mentations,  because  in  order  (p  validate 
»  given  compiler,  one  must  consistently 
ptuvidc  Ada  I/O  regardless  of  the 
underlying  host  implementation. 

fCH.  and  CAIS  differ  in  several  areas 
winch  arc  impoitunt  nr  note; 
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•  Pcte  supports  a  concept  of  schemas, 
subschemas,  and  the  notion  of  working 
schemas.  These  can  be  used  to  restrict 
the  logical  view  of  objects  and  to  control 
relationship  and  attribute  mapping  to 
objects.  Nodes,  classes  of  relationships, 
and  attributes  are  typed.  Pcte  does  not, 
however,  perform  any  process  to  object 
type  checking  during  execution  (there  is 
debate  as  to  the  implementability  of  pro¬ 
cess  to  object  type  checking  in  real 
time). 

•  Pcte  supports  transparently  distributed 
processing  on  multiple  (heterogeneous) 
workstations  and  processors  sharing  a 
Local  Aiea  Network. 

•  Pcte  provides  binary  code  compatibility 
with  unix  System  V.2  tools;  programs 
which  are  only  obtainable  in  binary  exe¬ 
cutable  forms  (and  cannot  be  recompiled 
or  relinked)  will  operate  properly. 

•  PCTE  provides  a  windowing  user  inter- 

f n  n.t 
Uvv. 

•  Pcte  provides  a  svro-likc  discretionary 
security  system,  which  is  different  from 
the  model  in  cais. 

<*  Pcte  has  no  software  provisions  for 
mandatory  security.  The  certification  of 
the  Scomp  system  provides  some  hope 
that  a  “hardware  hack”  could  be  used  to 
implement  mandatory  security  for  a 
pcte  implementation.  It  is  also  possible 
to  use  the  view  restrictions  afforded  by 
the  Schema  capabilities  to  implement 
some  security  functionality. 

In  general  the  primitives  in  pcte  can  be 
mapped  to  the  primitives  in  CAJ3  and  vicc- 
versa.  Mappings  from  cais  to  pcte  arc 
nearly  complete,  though  cais  lack?  some  of 
the  functionality  provided  in  PCTE,  It  is 
interesting  to  note,  however,  that  the  differ¬ 
ences  between  Ada  and  svid  stylo  impact 
the  apparent  granularity  of  primitive  opera¬ 
tions.  I  or  example,  let  us  compare  opening 
a  node  handle  in  the  two  systems: 

CAIS  call  to  vp*n  a  ttudft  hand  I*  njfto 
flM  ft  tun*  limit,  ftttliftr  »  r.htrftclftr  path 
ruun«  or  k  bftftft  nod*  and  relatloUfiilp  ft  urn 
llifti  b*M  i«i>Ua,  and  *n  litftnl  apftcijicftltoii 
IhwM  M«  on*  Uftitterflkin  to  ftll  A  lift  inogifttn 
(lliouftli  vli*7  lofty  rft|<r***iit  my  mimLftr  o( 
lgw-l»*«l  ojr«ftlluii»  Ui  Mi  kii|4fttiiftul4Uoii) . 


Th«  PCTE  equivalent  r-qiurw  uvtrtl  |r*m«l 
and  ufttr  Ubiuy-roulin*  operation*:  allocat¬ 
ing  a  currant  obj«et  («.g.,  the  nodft  handle], 
performing  an  aXarm(tun«  limit),  a  function, 
chrefobj (  ),  co  make  thft  currant  objact 
equivalent  to  th*  path  to  tha  nod*,  and  a  pot 
ciLlft  todr(  )  operation.  Th«*«  »*parat« 
opa-'fttionft  might  be  n«ct*cary  at  th*  "C" 
interface  lft-.«l  if  thft  "C”  umt  wi*h#d  to  per¬ 
form  th<  earn*  operation*  at  thft  CAIS  Ada 
ua«r. 

Another  visible  difference  berwten  cais 
and  pcte  is  in  the  handling  of  errors.  With 
cais,  the  Ada  style  of  exception  raising  is 
used,  while  with  pcte,  the  svid  style  of 
error  returns  is  used.  Generally  most  imple¬ 
mentors  of  Ada  compilers  map  the  error 
returns  of  svid  implementations  into  excep¬ 
tion  returns  anyway,  so  this  is  more  a  differ¬ 
ence  of  language  usage  style  than  an  impor¬ 
tant  one.  There  are  a  few  ambiguities  of 
error  return  to  exception  mappings,  but 
these  are  minor. 

Process  control  primitives  differ.  For  exam¬ 
ple: 

CAIS  a  sing!:  fur.-iicn  cal!  -  uasd  to 
■pawn  a  proctM. 

With  PCTE,  thft  •qui'fftlont  functionality 
would  require  a  *tart(  )  (of  th*  p  roc  cm),  a 
powtblft  «tartact(  )  (tramaction  locking  pruru- 
tiv«),  a  crobj(  )  to  ervata  tha  nod*  mod*! 
object  i iprftaftntftticn  for  th*  procan  nods,  a 
number  of  Mtattr(  )  call*  to  ftftt  thft  ftttnbutu 
up  for  th*  procftft*.  and  a  po«eibl«  lock(  )  call. 

Of  coutm,  it  i*  quit*  likftly  that  ft  (pftciflc 
CAIS  iiriplftmantation  would  break  a  piocwa 
■pawning  function  call  down  to  a  numbtr  of 
rubfunction*  anyway;  howavti ,  thft  uw  m« 
a  higher  Itval  of  abftract.on  of  function  call. 
(Thur«  in  dibatft  u  to  th*  value  of  abatrac- 
tioil  gramuiuiiy  in  tin*  rtgoru.) 

7.  Conclusion 

This  brief  report  discusses  why  we  have 
cais,  how  cais  might  be  and  has  been 
implemented,  and  how  cais  is  very  close  to 
the  svili  extensions  now  being  implemented. 
The  author  strongly  recommends  svid  as  a 
means  of  implementing  cais. 
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A  Basis  for  a  Portable  Common  Tool  Environment 
(PCTC) 

Daalgn  guidelines 
PCTE  project  team*- 


This  paper  outlinaa  th«  organisation  eh*  PCTE  project  and 
describes  the  fundamental  guidelines  which  inspired  the  PCTE 
design  efforts.  Finally,  it  also  presents  the  main  aspects 
and  the  rationale  for  the  PCTE  implementation  strategy. 


1.  The  PCTE  project 

The  project  “A  Basis  for  a  Portable  Common  Tool  Environment  (PCTE)’  is  car¬ 
ried  out  by  a  consortium  led  by  Bull  (France)  and  including  CEC  and  ICL  (United 
Kingdom),  Nlxdorf  and  Siemens  (Federal  Republic  of  Germany)  and  Olivetti  (Italy). 
The  purpose  of  the  project  is  to  design  and  implement  a  software  system  to  serve 
ss  basis  for  the  development  of  complete,  modern  Software  Engineering  Environ¬ 
ment  s. 

The  project  started  at  the  end  of  of  1983  and  is  to  run  for  a  period  of  four 
years.  Within  the  Consortium,  Bull,  ICL  end  Siemens  Jointly  develop  the  UNIX* 
baaed  PCTE  veralon;  Olivetti  ia  responsible  for  the  early  Implementation  of  a 
PCTE  prototype  and  for  a  longer  term  Ada**  version  of  PCTE;  GEC  and  Nlxdorf 
develop  two  sample  tools:  the  Knowledge  Based  Programmer  Assistant  and  the  Confi¬ 
guration  Management  System.  These  cools  will  exercise  and  demonstrate  the  validity 
of  the  PCTE  design. 

The  project  milestones  and  deliverables  are  defined  so  thac  intermediate 
results  from  the  project  can  become  visible  and  available  to  the  ESPRIT  community 
In  time  to  be  the  basis  for  tha  integration  and  the  dissemination  of  the  results 
of  other  BAD  projects.  The  first  result  of  ths  projtct  ha*  been  the  production  of 
tha  PCTE  Functional  Specification  Report.  The  F.S.  report  gives  the  detailed 
definition  of  the  PCTE  functionalities  in  a  form  which  can  directly  be  used  in  the 
design  of  tools  and  program*  which  will  eventually  be  lnttgrated  into  the  PCTE 
hotting  framework. 

PCTE  will  be  dtvcloped  In  close  cooperation  with  ocher  ESPRIT  projects,  in 
particular  with  CRASP1N  (graphical  a pecif lcar.icm  and  formal  implementation  of 
son-«*ou*ntlal  Systems),  SFMMS  (Software  Production  and  Maintenance  Management 
System)  and  the  ROSE  inf raatructure  project. 

Thle  paper  concentrates  on  tha  discussion  of  the  overall  PCTE  design  guide¬ 
lines;  cha  actual  functionalities  of  PCTE  are  described  in  the  PCTE  Functional 
Specification  report  (the  third  edition  of  which  is  publicly  available  inside 
ESPRIT) . 


*■  contact  person:  Mr.  J.P.  Bourguignon 

PCTE  programs*  manager 
Bull  -  DRTG/GL  -  5BF23 
88,  Route  de  Versailles 
78430  Louveciennes 
FRANCE 

*  UNIX  is  a  trademark  of  AT&T  Bell  Laboratories 
**  Ad*  i*  a  trademark  of  the  Ada  Joint  Frogram  Office 
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2.  Introduction 


The  «re«  of  Software  Technology  It  one  of  the  five  areae  of  tha  ESPRIT  pro- 
grtaaa  which  are  recognised  aa  prlorltary  In  order  to  praaarve  and  improve  the 
competitiveness  of  tha  European  Information  Technology  Industry.  Projects  under¬ 
taken  In  the  S.T.  as  well  as  in  tha  other  ESPRIT  areas  will  require  software  to  be 
developed  and  exchanged  by  various  tsama  all  over  the  Cosnunicy.  This  aspect  haa 
led  to  tha  notion  of  a  common  environment ,  to  be  used  by  the  different  research 
teaas  Involved  In  ESPRIT,  and  facilitating  not  only  the  development ,  but  also  the 
axchange  of  software  between  the  teams.  Such  an  environment  should  provide  a  suit¬ 
able  basis  for  the  vcrloua  projects,  and  be  available  on  different  categorise  of 
machines,  to  as  to  cover  tha  needa  of  the  various  teaas. 

A  suitable  Software  Engineering  Environment  (SEE)  should  offer  specific 
facilities  chat  are  generally  not  found  in  conventional  aysteaa.  The  natural  con¬ 
clusion  Is  therefore  to  use  a  dedicated  system  for  development  activities,  dis¬ 
tinct  from  the  machines  for  which  the  software  la  developed.  This  host/target 
development  paradigm  is  generally  admitted  In  Che  context  of  embedded  systems,  but 
appears  more  and  more  necesaary  also  In  the  context  of  general  data-proceaalng 
Systems,  In  which  the  specific  requirements  of  development  activities  are  often 
seen  as  nuisances. 

Software  development  la  accomplished  more  and  more  with  the  new  generation  of 
personal  workstations  linked  together  by  faac  Local  Area  Networks,  These  worksta¬ 
tions  era  personal  computers  with  pointing  devices  and  high  resolution  raster 
displays  Capable  of  supporting  several  character  sacs  and  graphics;  tha  LAN  facil¬ 
ities  can  provide  each  workstation  with  several  service* ,  such  aa  file  and  data 
base  services,  print  services,  software  development  services,  and  communication 
services,  both  atore-and-forvard  (a.g.  electronic  mall)  and  dialogue  (conversa¬ 
tional),  The  main  edvantage  of  time*  kinds  of  environments  is  thst  they  put  tha 
power  of  «  time-sharing  system  In  an  lonudlate  and  direct  fashion  Into  tha  nands 
of  one  uaer,  allowing  tha  user  to  carry  on  several  different  or  related  activities 
aa  they  best  suit  hie  needs  and  preferences. 

The  PCTE  takes  into  account  the  current  evolution  towards  advanced  worksta¬ 
tions  and  the  use  of  local  area  networks,  and  defines  basic  concepts  for  Software 
Engineering  Environments  which  esn  bs  adapted  for  both  conventional  and  distri¬ 
buted  eye  terns.  Thus,  the  distribution  of  functionalities  Is  an  Important  fact'  r, 
and  che  human  Interfaces  art  oriented  towards  tha  beat  use  of  modern  technology. 
However,  because  FCTE  should  be  usable  In  realvorld  contexts,  where  conventional 
hardware  (main  frame*  and  CRTs)  will  main  installed,  the  envlrorment  should  also 
operate  In  such  cooeexta.  Of  course,  Information  will  be  available  In  a  laaa  com¬ 
fortable  fashion  on  conventional  systems. 

Moat  software  engineering  tools  that  are  presently  available  result  from 
individual  effort*  and  tend  to  constitute  s  collection  of  vaguely  related  pro¬ 
ducts,  each  filling  a.  particular  function,  but  without  much  consideration  for  the 
software  development  procsss  as  a  whole,  On  tha  other  hand,  research  In  software 
technology  will  lead  to  che  Implementation  of  a  variety  of  Integrated  tool  sets  ru 
support  theories,  methods,  and  production  of  software.  These  tools  will  most 
likely  be  developed  in  the  context  of  different  projects.  It  is  therefore  Impor¬ 
tant  that  PCTE  offers  s  structure  based  on  stste-if-th*-arc  technology  chac  can: 

-  reduce  the  development  costa  of  software  tools,  contributing  to  their 
widespread  uas,  and  therefor*,  to  an  Improvement  of  software  productivity. 

-  facilitate  the  exchange  of  software  (tools  and  products  based  on  the  PCTE  pub¬ 
lic  common  tool  Interface)  among  the  European  software  community. 
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-  allow  lot  *nd  encourage  th«  Integration  of  tool*  In  comprehensive,  uniform  and 
homogeneous  Sofcwara  Engineering  Environments; 

-  speed  up  tha  dissemination  of  Ideas  sod  teehuluua*  among  and  between  the  Indus¬ 
trial  and  cha  rataarch  communities  by  providing  a  canon  fra«  of  rafersnc*. 

-  support  tha  smooth  transition  frca  existing  practices  by  allowing  tha  stay 
migration  Into  PCTE  of  existing  cools. 

These  conaidaratlona  naturally  lead  to  tha  concept  of  a  unifying  framework  that 
could  be  used  for  the  development  and  Intagratlon  of  a  variety  of  tools  In  order 
to  constitute  a  family  of  coaplate  envlromenta,  each  ona  with  Its  owu  specific 
characteristics  In  tarns  of  aechoda,  application  area,  etc. 

The  PCTE  project  la  aimed  to  the  definition  and  the  inpleaentalon  of  a  common 
framework,  within  which  various  software  tools  can  be  developed,  Integrated  and 
exchanged  so  a*  to  provide  couplet*  environments  for  software  engineering.  Dif¬ 
ferent  trends  in  software  technology  are  focused  In  PCTE: 

-  tha  openness  of  an  envlrornenc,  encouraging  people  to  develop  their  own  tools 
es  epitomised  by  UNIX; 

-  the  need  to  conceive  en  environment  around  powerful  mechanisms,  especially  In 
cha  area  of  object  management,  corresponding  to  tha  Stonaman  philosophy; 

-  cha  Improvement  of  programmers'  productivity  by  means  of  powerful  user  Inter* 
faces,  an  avenue  explored  especially  in  tha  Interlisp,  Hess,  Smalltalk,  and 
Cedar  eovlroaencs  developed  at  Xerox  PARC. 

As  common  framework  for  advanced  software  engineering  environments,  PCTE  can  have 
a  significant  Impact  on  the  European  Software  Technology  Industry;  however,  tha 
objectives  of  cha  PCTE  Initiative  can  only  be  achieved  if  PCTE  will  become  avail¬ 
able  sufficiently  early  to  ha  uaed  effactivaly  within  ESPRIT  projects  and  if  lc 
can  gain  sufficient  acceptance  Inside  ESPRIT,  aa  wall  aa  Inside  tha  Industrial 
community  at  large,  to  demonstrate  its  aulcabllty  aa  da  facto  standard. 

Thus,  th#  PCTE  me  In  objactivs  Is  to  provide  s  powirful,  state-of-the-srt  sys- 
tam  that  offsrs  high-level  mechanisms  for  tha  development  aud  Integration  of  a 
variety  of  software  cools.  However,  the  success  of  tha  PCTE  initiative  also 
rails#  on  Cha  achievement  of  two  Min  atrsteglc  goals: 

-  Portability:  PCTE  shall  provide  an  environment  that  can  be  made  available 

quickly  on  a  wlda  scale  without  inci.rlng  large  costs. 

-  Compatibility:  PCTE  shall  allow  a  smooth  transition  from  existing  software 

development  practices. 


3.  PCTE  preferred  architecture 

A  state-of-the-art  development  environment  has  to  provide  above  all  a  great 
comfort  Of  use.  Such  comfort  can  be  characterised  by: 

-  tha  raw  power  available  to  tha  user  In  terms  of  instant  computing  power  and 
large  storage  capacity; 

-  tha  quality  of  tha  dialogues  with  the  machine:  one  of  the  key  elements  there  Is 
the  eo-caJ  led  bandwidth  of  the  flow  of  Information,  whereby  for  a  given  effort 
from  the  user,  on*  can  Increase  the  amount  of  information  entered  or  displayed; 
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-  tha  overall  ease-of-usa  of  the  system; 

-  tha  gsneral  availability  of  tha  facility. 

That*  considerations  quickly  led  to  the  conclusion  that,  although  tha  system 
should  be  available  on  a  large  variety  of  machines  and  architectures,  there  was  an 
optimal  choice  on  which  we  should  focus  our  efforts. 

The  preferred  architecture  would  consist  of  powerful,  single-user  worksta¬ 
tions  offering  e  reasonable  mount  of  local  computing  power  (0.5  -  1  Mips)  and 
main  storage  (at  leaat  2  Mbytaa).  Thai#  vorkatatlona  should  be  equipped  with  a 
high- resolution  display,  capable  of  tha  textual  and  graphic  representation  of 
large  quantities  of  intonation  (corresponding  to  ssversl  A4  pages),  and  some 
pointing  device. 

However,  It  is  Important  to  rcsllse  thst  ths  devalopment  of  s  Isrge  or  com¬ 
plex  plecs  of  software  results  shove  all  from  ths  work  of  a  tsaa.  This  should  be 
reflected  in  the  envlromtnt,  which  should  be  an  environment  for  s  project,  end 
not  only  for  Individuals.  The  various  workstations  must  therefore  be  connected 
physically  so  that  s  uaar  working  on  one  workstation  can  access  information 
located  on,  or  communicate  with,  other  workstations.  They  must  alto  be  connected 
logically  ao  aa  to  treat  a  near  ea  an  actor  in  a  larger  context,  rather  than  aa  an 
Individual  who  Interacts  with  other  individuals. 

Tha  architectural  support  ean  thus  be  »i«:n  aa  constating  of  a  aat  of  worksta¬ 
tions  connected  through  a  high-bend width  local-area  network  and  sharing  common 
physical  and  logical  resources  ( "servers")  such  as  printers,  disks,  coauaunicstlon 
channels  or  *n*ctaliead  orocstsors. 

Ths  software  architecture  should  howwver  preserve  the  visibility  of  .a  unique 
sec  of  rasourcas  accessible  to  everyone .  In  other  terms,  we  should  have  a  single 
system,  whose  resources  ere  distributed  In  a  transparent  manner  among  tha  various 
physical  components,  end  not  a  number  of  individual  systems  that  have  to  communi¬ 
cate  explicitly.  This  Insistence  on  the  transparency  of  ths  distribution  Is  seen 
as  fundamental  If  we  want  to  preserve  tha  portability  of  tha  syetea  towards  dif¬ 
ferent  kinds  of  boats. 


4.  PCX*  design  objectives 

We  detail  below  the  principal  Individual  objectives  chat  we  scrlved  for  dur¬ 
ing  the  design  of  ?CTE  facilities,  sad  hot?  these  caw  be  Interpreted  In  the  context 
of  the  resulting  functionalltier . 


4.1.  Ca natality 

The  hosting  structure  should  be  capable  of  providing  the  basis  for  a  number 
of  environments,  differing  in  such  aspects  ss  the  application  domains,  the 
development  methods,  tna  project  organisations ,  or  tha  programming  languages  used. 

Tha  basic  environment ,  on  tha  ocher  hand,  provides  powerful  mechanisms  upon 
which  these  specialised  environments  ean  be  built  and  operated,  the  mechanisms 
should  therefore  cater  to  e  variety  of  needs,  offering  the  maxima  relief  to  the 
tool  developer,  while  avoiding  any  interference  with  his  design  decisions. 

Of  particular  importance  In  this  rsspact  Is  the  need  to  separate  the  mechan¬ 
isms  from  the  policies  that  can  govern  their  use.  The  basic  environment  should 
offer  ways  to  control  the  use  of  the  various  primitives,  but  should  not  Impose  any 
control  of  Its  own. 
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4.2.  flexibility 


A  consequence  of  the  approach  described  above  la  Chat  the  at  rue  tun  a  use  ba 
adapted  to  a  variety  of  needs.  This  tailoring  can  ba  achlaved  affectively  If  the 
baaic  primitives  offered  are  themselves  fairly  simple,  but  tapreaent  a  coopiate 
set  of  functionalities.  Thus,  '.t  It  always  possible  to  build  aora  complex  func¬ 
tions  on  top  of  the  basic  ooas,  thereby  tailoring  the  upper  layer  that  will  be 
made  visible  to  the  end  user. 

It  is  important  not  to  ba  preemptive  in  this  respect,  and  to  recognise  the 
existence  of  three  categories  of  actors  dssllng  with  tht  environment: 

-  The  tool  developers  construct  tools  end  software  layers  as  to  tailor  the 
envlrooaent  to  specific  needs. 

-  Tha  SEE  architect  construct*  an  integrated  project  support  environment  with  the 
PC7E  and  Che  appropriacaly  chosen  cools. 

-  The  sod  user*  aerely  use  an  environment  together  with  its  tools  in  the  context 
„f  their  daily  work. 

The  design  has  to  cater  for  the  needs  of  Cool  developers,  SEE  architect  end  end 
users;  the  three  categories  represent  the  'users’  (in  a  general  aense)  of  the  eye- 
tea. 


4.3.  Hoaogenaicy 

One  of  the  aoat  salient  demands  placed  on  an  environaenc  from  the  user's 
point  of  view  la  the  homogeneity  among  a  given  set  of  tools,  aa  well  as  of  the 
environment  as  a  whola.  Homogeneity  appears  at  thrae  diff treat  levels: 

-  A  logical  level  which  correeponde  to  the  functions  performed  by  the  various 
tools:  each  tool  should  have  a  precise  function  that  eompleaenta  axactly  those 
of  other  toola,  without  overlapping  with  then.  Within  tha  context  of  e  particu¬ 
lar  development  approach,  each  tool  has  its  place,  and  tha  whole  eat  of  tools 
should  provide  complete  support  throughout  development  and  operational  use. 

-  An  Internal  level  corresponding  to  tha  object*  and  operations  accessed  by  the 
tool.  Thee*  are  governed  by  tha  facilities  offered  by  the  basic  system,  but 
also  by  design  choices  regarding  tha  various  cools,  such  as  che  internal 
representations  of  the  manipulated  iaferrseticn  which  Bust  be  consistent  between 
tha  various  toola. 

-  An  external  laval  which  defines  tha  interface  between  tha  end  uaer  and  che 
Cool.  It  la  important  chat  che  aan-machlns  intarfacas  for  tha  varloue  tools  be 
uniform  and  consistent. 

The  logical  leval  Is  mainly  dependent  on  the  choice  of  a  particular  development 
approach  and  of  the  associated  cools.  The  Internal  leval  is  also  largely  depen¬ 
dant  on  Implementation  choice*.  However,  tha  basie  environment  can  Indeed  foecsr 
the  homogeneity  of  operations  and  the  Integration  among  tha  various  tools  by 
offering  an  adequate  eat  of  functionalities ,  well  adapted  to  the  particular  needs 
of  tool  development.  The  notion  of  Software  Engineering  Database  is  clearly  cen¬ 
tral  to  tbls  laaue;  therefore,  the  Object  Management  System  Is  considered  as  a 
central  feature  of  PCTE. 

Ac  tha  external  level,  much  can  be  done  co  promote  homogeneity  as  perceived 
by  che  and— user:  the  form*  of  dialogue,  the  style  of  cucnmand  languages,  the  provi¬ 
sions  for  on-line  assistance,  cen  be  defined  at  the  level  of  an  entire 
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environment,  and  supported  by  mechanisms  and  matt-cools  Chat  can  facilitate  their 
adaptation  to  a  particular,  (Ivan  tool. 


4.4.  Portability 

Two  male  phaaaa  and  two  complementary  approach*!  ara  idantlfled  for  tha 
Implementation  of  PCTE  basic  r  henisss: 

-  A  aadltsa  tana  phara,  eantrad  around  portability  of  toola  which  acraataa  eompa- 
tlblllty  with  UNIX  aa  tha  means  to  exploit  and  rauaa  tha  larga  pool  of  existing 
UNIX  toola. 

-  A  longer  ns  phase,  centered  around  Ada  and  a  portabla  architecture  to  obcaln 
the  highest  degree  of  portability  of  PCTE  basic  mechanisms. 


4.4.1.  Tha  UNIX  based  phaaa 

Tha  technical  approach  to  portability  reflect*  tha  will  to  achieve  a 
widespread  availability  of  tha  PCTE  both  la  a  short  tlae  frame,  and  in  a  coat- 
effective  manner.  Due  to  tha  portability  of  UNIX  and  lta  wide  availability  the 
development  la  baaed  on  extensions  Co  UNIX.  This  la  tha  beat  compromise  to  tran¬ 
sport  tha  PCTE  onto  a  wide  vatitty  of  machines  at  a  reasonable  coat  and  In  a  short 
time-scale. 

Tha  requirements  for  coapatlbllty  with  the  existing  practices  and  for  a 
quick,  widespread  availability  hes  lad  us  to  decide  on  a  UNIX-based  Implementation 
strategy.  However  UNIX  le  far  from  being  a  distributed  system.  Trying  to  rewrite 
tha  UNIX  kernel  to  fit  on  a  distributed  architecture  would  go  against  our  goal  of 
being  able  to  rehost  tha  environment  on  exlatlng  UNIX  systems. 

So  as  to  assure  portability,  a  layer  of  communication  facilities  will  be 
added  onto  UNIX  so  a*  to  provide  a  base  of  communicating  nodes,  each  on*  running  a 
separata  UNIX  system.  Tha  mechanisms  and  functions  of  the  enviroment  Itself  will 
ba  Implemented  as  one  global  syatea  on  top  of  tha  collection  of  Individual  UNIX 
systems. 


4.4.2.  Tha  Ada  baaed  phase 

Tha  above  anmlTals  concerns  machines  for  which  UNIX  la  already  available 
(l.a.,  vi*  do  not  Incur  tha  cost  of  transporting  UNIX  Itself).  On  tha  ocher  hand, 
should  UNIX  have  to  ba  transported  ax  wall,  then  tha  approach  might  ba  recon¬ 
sidered.  This  la  tha  basis  for  undertaking  a  complementary  implementation  of  the 
PCTE  folly  written  In  Ada,  In  top  of  a  minimal  portability  kernel. 

An  alternative  Implementation  in  Ada  of  the  basic  scchfinlama  la  thus  the  long 
term  goal  of  tha  project.  Tha  approach  straasaa  tha  portability  of  PCTE  basic 
mechanisms  and  thus  of  SEZs  built  on  top  of  it  on  syntaas  which  are  not  con¬ 
strained  to  tha  UNIX  family.  A  key  Issue  Is  tha  definition  of  an  internal  porta¬ 
bility  level  which  can  ba  easily  mapped  on  top  of  a  variety  of  Operating  Systems. 

Tha  ef factlvanaaa  of  this  alternative  stems  from  tha  belief  that,  in  the  long 
run,  Ada  compilers  will  be  available  for  a  large  number  of  machines.  Tha  choice  of 
Ada  it  baaed  on  the  two  following  considerations : 

-  Ada  Is  •  modern  language  specifically  designed  for  writing  portable  and  reli¬ 
able  system  software 
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Adi  is  expected  to  become  widely  accepted  in  the  RaD  community. 


The  approach  it  also  Justified  by  the  fact  chat  market  pretsur**  will  cause  Ada 
compilers  co  be  developed,  independently  cf  the  nerd  for  the  FCTE. 

This  dual  (UNIX  and  Ada)  approach  is  aixed  at  providing  the  best  portability 
within  different  else  frames;  these  considerations  should  not  have  an  Impact  on 
the  users  of  the  envlroiasenc ,  who  should  see  the  same  sat  of  primitives,  the  FCTE 
common  tool  interface,  and  use  them  in  exactly  the  aaae  way.  Thus,  the  tools 
developed  for  the  UNIX  based  ?CTE  will  still  b«  portable  to  the  Ada  baaed  Imple¬ 
mentation,  which,  according  to  the  multilanguage  nature  of  PCTE,  will  also  offer 
conaiscent  C  language  interfaces. 


4.5.  UNIX  compatibility 

The  support  for  migration  path  from  UNIX  based  environments  to  PCTE  Is  a 
principal  short  term  goal  of  the  project.  This  la  a  vital  factor  which  will  deter¬ 
mine  the  future  role  of  PCTE.  In  Chit  connection  PCTE  hea,  first  of  all  co  gain 
accaptancs  u  a  raady  available,  easy  to  edopt  alternative  to  existing  practice*; 
it  must  be  possible  for  tools,  data  and  people  (project  team*  or  Individual  users) 
to  migrate  towards  the  new  environment  with  a  minimus  of  efforts.  The  key  issue 
In  this  respect  1*  the  ability  to  directly  reuse  existing  tools,  thus  the  absolute 
requirement  for  a  complete  compatibility  of  PCTE  facilities  with  the  corresponding 
UNIX  ones. 


5.  Implementation  strategies 


5*1.  Exodus  -  moving  to  PCTE 

A  reference  scenario  Is  envisaged  which  describee  the  migration  of  projects 
from  an  existing  environment  to  PCTE.  The  preferred  situation  assumes  this 
environment  being  based  on  UNIX  System  V  running  on  either  some  (LAN  of)  work¬ 
stations  or  on  a  minicomputer .  Moving  from  UNIX  based  SEEa  co  PCTE  can  actually 
be  carried  out  simply  by  exploiting  the  up-ward  compatibility  of  PCTE  with  UNIX. 
On  the  other  hand,  PCTE  offers  much  more  powerful  capabilities  and  further  evolu¬ 
tion  possibilities  which  can  be  taken  into  account  from  the  Initial  phases  of  the 
migration  process. 

The  migration  of  s  project  from  one  SEE  to  an  other  implies  the  transport  of 
the  cools  sod  data  structure  supporting  projact  team  activities  and  to  reproduce 
ou  the  new  system  Che  characteristics  of  the  operational  environment  the  projecc 
team  members  are  familiar  with.  The  most  obvious  aspect  1*  the  emulation  of  the 
CRT  style  of  User  <“>  System  interaction  protocol:  though  the  adaptation  of  the 
user  co  the  more  advanced  facilities  of  FCTE  User  Interface  (windowing,  pointing 
devices,  menus)  can  be  achieved  at  no  cost,  environment  users  should  be  allowed  to 
reuse,  at  least  In  the  initial  steps  toward  ths  new  facilities,  features  such  as 
shell  scripts,  aliasing  and  profiling.  Thus  Che  UNIX  ahe.ll  has  to  be  made  avail¬ 
able  to  make  che  adaptation  easier  for  Che  human  user  who  should  also  be  able  to 
exploit  PCTE  specific  facilities  such  as  che  control  of  Activities  and  the  estab¬ 
lishing  of  Working  Schtmat. 

The  migration  of  project/ user  data  from  existing  File  Syattm  structures  Into 
the  PCTP.'s  Object  Manageaent  System  (OHS)  base  can  eaally  be  achieved  by  copying 
the  hierarchical  File  System  structure  Irto  the  OMS.  Such  structure  could  later  on 
gradually  evolve  to  exploit  the  augmented  power  of  the  data  model,  for  Instance  by 
establishing  additional  relationships  representing  non-hlerarchical  dependences 
among  objects;  the  original  hierarchical  structure  (as  well  as  the  extended  one) 
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cun  still  be  accessed  by  tool*  developed  to  run  on  UNIX. 

The  explicit  goal  of  the  PCTE  project  it  to  eupport  directly  the  immediate 
reueabllity  of  toola  developed  to  run  on  System  V  (end  thus  of  ell  UNIX  tool* 
which  do  not  rely  oo  some  facility  epeclflc  to  *  given,  non  System  V  vertlon  of 
UNIX).  Thu*  the  existing  tools,  as  for  date  items,  can  be  lnatalled  In  the  OKS 
base  and  can  be  executed  In  cha  PCTE  framework.  Civen  the  number  of  tools  one  can 
expect  to  find  on  a  given  UNIX  Installation,  the  only  suitable  avenue  (from  the 
user  point  of  view)  la  an  installation  procedure  which  does  not  require  to  aodlfy 
the  toola.  Actually,  the  beat  solution  It  the  installation  of  tools  by  just  copy¬ 
ing  the  tool  executable  representation  into  the  OHS  base. 

In  general,  UNIX  baaed  tool  sate  will  not  exhibit  the  properties  one  expects 
for  proper  Softvare  Engineering  environments,  especially  in  terns  of  Integration, 
of  management  of  complex  information  bases  and  of  friendliness  of  the 
tool  <“>  user  Interfaces:  new  cools,  designed  end  developed  to  take  advantage  of 
the  advanced  PCTE  facilities  will  gradually  become  available  to  be  Integrated  into 
consistent  SEEs.  However,  cha  ability  to  reuse  existing  tools  will  play  a 
paramount  role  in  the  initial,  critical  phaaea  In  which  transition  to  PCTE  based 
SEEs  has  to  take  place. 


5.2.  U8IX  compatibilty 

Compatibility  with  UNIX  In  the  context  of  tha  emerging  standardisation  ini¬ 
tiatives  (Syaeam  V  Interface  Definition  and  X/OPEN/GRQUF)  has  bean  a  clear  mandate 
for  ttva  design  of  cha  PCTE  baaic  mechanisms :  compatibility  with  UNIX  la  achieved 
by  as  emulation  of  the  UNIX  System  Call  functional  level.  Two  complementary  stra¬ 
tegies  are  adoptee: 

-  Some  basic  PCTE  facilities  have  a  one-to-one  correspondence  with  UNIX  primi¬ 
tives:  the  as  keep  ths  same  Interface  specification  (tha  *C"  language  function 
definition,  type  and  number  of  formal  parameters)  as  the  corresponding  UNIX 
primitive.  However  tha  semantics  of  the  baaic  PCTE  operations  are  In  general 
extended  via-a— via  UNIX. 

-  UNIX  primitives  which  have  not  a  direct  correspondence  with  soma  PCTE  basic 
function  are  still  Included  to  serve  the  purpose  of  compatibility.  However,  the 
same  functionalities  may  also  be  achieved  by  some,  more  general  basic  mechanism 
function. 

-  UNIX  concepts  such  as  file  system,  davits,  preens:,  css  else  be  interpreted  In 
tha  context  of  PCTE,  though  tha  corresponding  PCTE  concepts  era  mote  general. 

An  important  effort  haa  been  dona  so  far,  and  it  will  vary  likely  have  to  ba  con¬ 
tinued,  to  insure  the  compatibility  of  PCTE  functional  specifications  with  the 
evolution*  of  tha  above  mantioned  standard  definitions  of  UNIX  interfaces. 


5.3.  Which  level  of  compatibility? 

Compatibility  between  PCTE  basic  mechanisms  and  UNIX  system  call  Interfaces 
allows  the  Importation  Into  PCTE  of  tools  developed  to  run  on  UNIX;  however,  com¬ 
patibility  can  b*  achieved  at  varloua  levels  according  to  the  program  representa¬ 
tion  which  la  addressed:  source  code  representation,  object  format  representation, 
executable  format  representations: 

1)  Source  level  compatibility:  this  level  is  addressed  in  the  PCTE  Functional 
Specification  report.  It  allows  the  transport  of  tools  for  which  the  source 
code  is  available  oy  recompilation  (and  possible  source  code  modification)  of 
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each  tool  co  be  ported  to  PCTE.  The  source  level  compatibility  la  Cha  easiest 
to  achieve  (fro*  Che  PCTE  implementors  point  of  view);  however.  It  implies  the 
most  difficult  procedure  to  ctanspcrc  toolt  to  PCTE:  first,  In  general,  source 
code  Is  not  available  for  tools  which  are  commercial  products;  second,  the  coo- 
pilatlon  of  several  tools  (there  are  hundreds  of  tools  os  a  typical  UNIX 
Installation)  say  in  Itself  be  e  non  trivial  task,  which  lnvolvea  making  avail¬ 
able  the  appropriate  'makefiles',  the  included  files  and  the  (aourcea  of  the) 
libraries  which  ere  Involved. 

2)  Object  level  representation  (the  '.o'  one);  this  level,  at  one  could  aspect, 
can  ba  uaed  aa  a  bast  for  porting  tools  across  compatible  hardwares.  The 
object  code  level  compatibility  lapllae  •  simplified  procedure  for  Installing 
(JM1X  cools,  however  the  availability  of  object  code  of  tools  can  still  be  a 
read  problee. 

The  object  code  compatibility  Is  nevertheless  s  candidate  strategy  for  PCTE 
implementations ,  which  presents  however  some  additional  drawbacks,  aa  dis¬ 
cussed  later  on  In  this  paper. 

3)  Executable  format  compatibility;  this  plays  a  very  Important  role  because  of 
lea  very  attractive  characteristic  of  ad  lowing  the  easiest  procedure  for  moving 
programs  between  different  environment*  and  In  particular  the  Importing  of 
existing  tool*  into  PCTE:  tools  need  juet  co  ba  copied  la  the  CMS  apace  and  are 
ready  to  be  run  via  PCTE  execution  primitives.  On  the  ocher  hand ,  executable 
format  compatibility  Implies  the  ability  of  capturing  all  UNIX  ayatesi  calls  at 
SVC  level  (trap)  to  redirect  them  to  PCTE.  Thus  Che  UNIX  kernel  would  have  to 
he  relinked  together  with  Che  PCTE  basic  mechanisms  and  the  SVC  table  (as  found 
In  ayaent.c,  for  unlx  gurus)  Co  be  extended  to  include  the  PCTE  functions. 


5.4.  Implementation  approaches 

Two  approaches  are  envisaged  for  the  UNIX  based  implementations  of  the  PCTE 
Interfaces:  these  will  exploit  the  object  and  executable  compatibility  levels  si 
specific  eolutloos  for  two  different  classes  of  hoar  environments: 

e)  Add-on  to  the  UNIX  kernel:  the  standard  Syatan  V  (AT&T)  implementation  Is  the 

reference  environment  on  which  PCTE  can  be  ported  at  virtually  no  coat  with  the 

beet  results.  In  this  spprosch,  the  PCTE  kernel  becomes  a  true  extension  to 
the  UNIX  one.  Thus,  tools  which  ere  already  available  on  a  given  System  V 
installation  art  compatible  at  tha  execucabla  format  level  and  can  be  directly 
Imported  Into  PCTE.  To  give  an  example  of  the  Importance  of  this  last  ispect, 
there  are  some  400  cools  already  available  under  Systea  V  on  the  Sell  f'S7;  feu 
•  up* r- guru*  (if  any  at  all)  know  all  these  cools  at  Che  level  that  could  other¬ 
wise  be  needed  to  transport  them  to  PCTE. 

Furthermore,  such  an  approach  can  cake  advantage  of  the  System  V  structure  to 
gain  on  efficiency,  especially  in  the  connection  with  a  critical  area  such  as 

the  a;S.  Bowever,  th*  boundary  between  PCTE  and  System  V  software  1*  clearly 

defined  (end  respected)  so  chat  Chert  1*  no  direct  dependence  between  PCTE  end 
Syets*  V  Internals. 

b)  “black  Box'  Implementation:  this  tarm  is  used  here  to  designate  *n  implementa¬ 
tion  of  PCTE  basic  mechanisms  which  lies  outside  Che  O.S.  kernel  and  it  organ¬ 
ised  a a  a  collection  of  user  level  processes.  The  principal  problems  which  are 
associated  with  this  approach  erf. 

-  existing  UNIX  tool*  are  to  be  relinked  with  new  system  call  libraries  In 
order  to  be  imported  into  PCTE. 
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-  performance:  *11  basic  operations,  Including  evaluations  of  path  ntati  would 
imply  passing  around  several  massages;  *  less  efficient  capping  of  OMS 
'volumes"  on  cop  of  UNIX  File  Systems  la  Implied . 

-  The  tvo  levels,  th«  PCTE  and  tha  UNIX  Interfaces  ara  both  a<  ceaslble  by 
cool*;  chua  PCTE  uaara  and  tha  OHS  data  (pact  naad  to  ba  protcccad  again* t 
native  O.S  uaara  for  consistency  and  accurity  aapacts.  These  issues  prtaant 
various  faacinatlag  implementation  problem*  which  ara  not  yet  entirely 
ao lead. 


5.3.  The  PCTE  prototype 

An  additional  aapect  of  tha  project  which  la  mentioned  to  complete  the  pic¬ 
ture  of  the  PCTE  development  atrategy  la  the  prototype  implementation  of  PCTE 
Interfaces  which  ha*  bean  carried  out  In  parallel  with  the  above  mentioned  UNIX 
baaed  phase. 

The  purposes  of  an  early,  prototype  implementation  of  the  PCTE  interface* 

are: 

-  it  can  aerve  inaid*  the  PCTE  project  aa  the  vehicle  for  the  verification  of  the 
completeness  and  tha  conaiacancy  of  the  PCTE  Interface*; 

-  It  can  promote  the  uaage  of  PCTE  by  providing  to  time  critical  ESPRIT  projects 
a  sound  baala  for  tha  comprehension  and  experimentation  of  PCTE  mechanisms; 

-  it  tan  ba  a  basis  frit  the  'Slack  Sax*  implement* Sion  of  PCTE  Interfaces. 

•  The  goals  of  tha  prototype  ar..,  thus  CO  make  availebl*  an  emulation  of  the  PCTE 

Interfaces  quickly  and  on  a  wide  range  of  host  envlronaents-  The  achievement  of 
such  an  objective  haa  been  poaelble  because  of  two  important  design  decisions: 

-  implementation  problem*  arc  simplified  by  not  having  to  address  strict  relia¬ 
bility  and  efflciancy  Issue*  and  concentrating  the  Implementation  efforts  cn  a 
C significant)  subset  of  PCTE  facilities; 

-  tha  prototype  Implementation  la  baaed  on  an  adaptation  of  the  results  of  the 
Portable  Ada  Programming  System  (PAPS)  project,  which  hat  been  developed  in  the 
context  of  the  CCC  Multi  Annual  Programme. 

The  major  emphasis  has  been  on  portability  of  the  prototype  across  different  ver¬ 
sion*  of  UNIX.  The  prototype  has  been  so  far  successfully  ported  on: 

-  System  V 

-  Berkeley  4.1  and  4.2 

-  Interactive  System  III 
*  MOSX 

-  MUHIX  1.4  and  1.5 

-  ULTRIX 


6.  Conclusions 

We  discussed  tha  principal  aspects  of  PCTE  in  connection  with  its  immediate 
and  long  tsrm  strategies:  compatibility  with  UNIX  and  adequateness  of  facilltlss 
to  the  needs  of  modern  SEEi  art  the  key  factor*  In  the  short  tent;  sventually, 
portability  of  PCTE  basic  mechanisms  will  become  the  principal  aspect  as  the  near, 
to  preserve  Investments  against  obsolescence  as  new  hardware  and  new  operating 
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Thu*,  the  abort  ton*  approach  1*  cantered  around  tool  portability  and  UNIX 
Syetta  V;  the  long  tern  atratagy  haa  been  concentrated  on  ayatea  portability 
adopting  Ada  and  an  architecture  which  atreaaaa  the  Independence  of  the  PC TE 
lapleaantaclon  froa  apeclllc  operating  ayettaa. 

However,  the  Initiative  will  auceeed  only  If  the  transition  to  PCTE  baaed 
SEE*  will  be  deaonatrarad  to  be  a  suitable  avenue.  Thla  la  Indeed  the  challenge 
of  the  Initial,  UNIX  baaed  pheae  of  the  PCTE  project. 


Onnlw  o  i 

teat 

A  lull  for  *  Portable  Cones  Teel  XavirecMSC 
PC7I  project  teamf 


This  paper  la  as  overview  of  PCTE:  it  outline*  as  user  view 
of  the  basic  features  of  PCTE.  The  focus  of  the  discussion 
Is  on  tbs  three  principal  aspects  of  PCTE:  the  Object 
Management  System,  the  Osar  Interface  and  thi  Distribution 
mechanism. 


1.  The  tCTZ  project 

The  project  'Seals  for  a  Portable  Common  Tool  Enviroment  (PCTE)'  la  carried 
out  bp  a  conaortlua  led  bp  Bull  (France)  and  Including  GEC  and  XCL  (United  Ring- 
dem) ,  Kixdorf  and  Siemens  (Federal  1* public  of  Germany)  end  Olivetti  (Italy) .  The 
purpose  of  the  project  la  to  design  and  Implement  a  software  system  to  serve  as 
basis  for  the  development  of  complete,  modem  Software  Engineering  Environments. 

The  project  started  at  the  and  of  of  1983  and  la  to  run  for  a  period  of  four 
yaara.  Hi  thin  the  Consortium,  lull,  ICX.  and  Sit maos  jointly  develop  the  OH  II* 
baaed  PCTE  version;  Olivetti  la  responsible  for  the  early  implementation  of  a 
PCTE  procotype  and  for  a  longer  term  Ada**  version  of  PCTE;  GEC  and  Hlxdorf 
develop  two  sample  tools:  Cha  Inowladge  Baaed  Programmer  Assistant  and  the  Confi¬ 
guration  Management  system.  These  cools  will  exercise  and  ueau&itr.ti  ths  validity 
of  ths  PCTE  design. 

Tha  project  nils  stones  and  dsllvarablte  are  defined  so  that  intermediate 
results  from  Che  project  can  become  visible  and  available  to  tho  ESPRIT  community 
In  time  to  be  tha  baala  for  the  Integration  and  tha  dissemination  of  the  results  * 
cf  other  BAD  projects.  Tha  first  result  of  the  project  has  been  the  production  of 
the  PCTE  Functional  Specification  3a port.  The  F.S-.  report  gives  the  detailed 
definition  of  the  PCTE  functionalities  In  a  form  which  can  directly  bo  used  in  tha 
design  of  tools  and  programs  which  will  eventually  be  lntegzeted  Into  the  PCTE 
hoetlug  framework.. 

PCTE  will  be  developed  lu  close  cooperation  with  ocher  ESPRIT  projects,  In 
particular  with  GRASPXN  (graphical  specification  and  formal  implementation  cf 
noo" sequential  Systems)  and  SPMKa  (Software  Production  and  Maintenance  Management 
System)  and  the  ROSE  Inf restructure  project. 


t  contact  person:  Mr.  J.P.  Bourgulgnon 

PCTE  programme  manager 
Bull  -  DBIC/CL  -  58P23 
68,  Route  a*  Versailles 
78430  Louveclscncs 
FRANCE 

*  UNIX  la  a  trademark  of  AT&T  Sail  Laboratories 
**  Ads  Is  s  trademark  of  the  Ada  Joint  Program  Office 
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2.  Overview- mf  the  basic  PCIZ  facilities 

PCTt  la  an  hosting  structure  designed  to  bv  eha  basis  for  tha  construction  of 
modern  Software  Engineering  Envlronanca  (SEE).  Each  PCTT  based  SEE  la  regarded 
as  ao  integrated  collections  of  cools  and  service*  specific  to  a  particular  pro¬ 
ject  life  dele  nodal  and/or  application  domain. 

In  tb«  nodal  architacturt  iaplisd  bp  eba  PCTt  approach  chare  la  a  dear 
aaparadoa  beevsan  tha  tool*  and  tha  underlying  structure  that  boats  than.  Indeed, 
sons  seemingly  central  aspect*  of  the  environment,  aueh  as  a  command  processor, 
are  r slags ted  to  the  tool  level. 

Tha  public,  common  tool  interface  to  the  PCTE  aarricles  It  daflnni  by  a  oat 
of  program-callable  primitive*  which  support  the  execution  of  prograa  In  terns  of 
a  virtual,  aachina  independent  level  of  ccaprehenaive  facilities.  Tha  following 
•actions  pretence  the  principal  aspects  of  PCTE  neatly: 

-  Tha  Eaale  Mechanism:  these  correspond  to  the  functionalities  required  to  mani¬ 
pulate  tha  various  entities  that  can  exist  in  a  development  context.  Theta 
entitle*  are  essentially  progress  chat  ean  ba  executed  (typically  tools,  or 
progress  under  test) ,  sod  various  objects  manipulated  by  the  programs  (dats 
objects,  such  ss  various  representation*  of  tha  programs  being  developed,  the 
documentation,  input  and  output  data;  and  also  physical  objacta  such  ao  Ceraj- 
nala  and  device  drivers). 

-  Tha  near  Interface:  above  the  basic  Bcchanlsaa,  which  deal  with  tha  internal* 
of  tools,  PCTE  provides  a  masher  of  facilities  to  assist  in  the  lonatructlon  of 
various  aspects  of  the  tools  that  will  b*  dlractly  visible  to  the  and  user- 
These  aspects  concern  tbs  font  of  dialogue  and  of  interactions  (exchange  «£ 
Information)  between  users  and  tools,  and  tha  graphic  facilities. 

-  Distribution:  although  not  a  direct  concern  to  tha  near,  tha  implementation  of 
tha  eovlromiant  on  a  network  of  workstations  requires  tha  definition  of  mechan¬ 
isms  and  protocols  to  support  tha  transparency  of  tha  distribution. 


3.  .  Basic  Mechanisms 

Tho  PCTE  Basic  Mechanisms  era  subdivided  into  five  categories:  Elocution, 
Communication,  Inter  Process  Communication,  Object  Management  System  and  activi¬ 
ties. 


9.1.  Execution  mechanl aaa 

The  execution  primitives  deal  with  the  ration  of  a  program  in  execution.  They 
define  how  an  execution  can  ba  started  or  teraiuated,  how  it  ean  ba  controlled, 
how  parameters  can  ba  passed  to  tha  program,  sod  more  generally  deflna  tha  rela¬ 
tions  between  a  running  program  and  tha  environment  within  which  it  execute*, 
facilities  ora  provided  for  running  a  program  (procass),  for  defining  and  control¬ 
ling  the  interactions  between  a  program  and  its  surrounding  context. 


3.2.  Communication  mechanisms 

Tha  communication  primitives  deal  with  ;h*  way  a  program  can  access  the  file 
type  unstructured  data  (contacts  of  objects)  which  are  kept  in  the  Object  Manage¬ 
ment  System  database.  They  correspond  to  convtnclooal  input-output  facilities  and 
are  closely  modelled  on  those  of  UNIX. 
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3.3.  Inter  Process  Cossaualcatlon 

Special  mechanisms  arc  provided  to  allow  different  processes  to  exchange 
information.  Although  these  could  ba  viewed  u  part  of  tho  coma uolcatlon  facili¬ 
ties,  or  of  tha  execution  facilities,  they  art  treated  specially  because  they  play 
an  important  rola  In  eha  implementation  of  tha  raat  of  tha  system. 

la  addition  to  traditional  UNIX  pipaa  and  signals,  PCTE  provides  a  anuir- 
passing  facility,  and  tha  poaalbility  to  shara  memory  segment*  batwaan  naara. 
Than*  naehaaisaa  ax  a  upward  compatible  with  eha  enaa  found  in  UMIX  System  V, 
although  ehay  of  far  loaa  additional,  aora  powerful  ftatccionalitiaa. 


3.4.  Tha  Object  Management  System 

A  key  aapact  of  an  environment ,  and  one  that  ha*  a  major  in  pact  on  tho  can" 
p laxity  of  the  tool-writing  process,  is  tha  set  of  functions  that  art  provided  to 
manipulate  tha  various  objects  in  tha  system. 

Tha  various  *»geatt"  in  tha  •svirocaent  (users  and  programs)  “operate*  on  a 
number  of  entltlaa  that  ata  known  to  tha  syatan  and  can  ba  daaignatad  In  it,  and 
that  are  globally  referred  to  aa  "objects*.  Thaaa  nay  ba  files  in  tho  traditional 
Sanaa,  peripherals,  pipes,  or  the  description  of  tha  static  contexts  of  a  program, 
but  also  object*  representing  information  items  tuch  as  project  milestones,  tasks, 
project  management  and  progression  record*. 

In  a  medium  sized  project,  a  huge  number  of  objects  are  created  which  may 
have  complex  relationships.  Among  tha  numerous  examples,  one  could  mention: 

-  taa  docugentntinn  and  tha  lootcn  code  of  •  pxugiaw  (UW  latter  say  itself  •  ce=- 
tain  several  nodules);  — 

-  tha  history  and  tho  derivation  trail*  for  a  given  version  of  a  given  object 
(representing,  a  program,  a  program  fragment,  a  document  or  other  items  to 
which  Configuration  Management  can  ba  applied). 

“  tha  teat  set  for  exercising  a  particular  version  of  a  nodule  with  the  set  of 
sample  raaulca  that  era  supposed  to  ba  produced  by  thaee  tests. 

A  uniform  treatment  of  che  various  dnasas  of  objects,  and  powerful  mechanisms  to 
store  and  designer*  these  objects,  ars  two  Important  requirement*  on  a  software 
engineering  environment.  The  natural  solution  la  a  system  that  allows  the  uaer  to 
associate  a  number  of  attribute*,  whose  value*  represent  specific  properties,  to 
[objects,  and  to  represent  the  various  relationship  >■  which  can  exist  batwaan 
objects. 

Tha  basic  OHS  wod«l  la  derived  from  tha  Entltlty  Relationship  data  nodal  (ER) 
and  defines  Object*  and  Relating* hip*  a*  being  the  basic  item*  of  tha  cnvlronasnc 
Information  base. 

Objects  ara  entities  (la  the  ER  Sanaa)  vhich  can  ba  designated,  and  can 
optlo.  ?Jlly  be  characterised  by 

-  a  "contents*  l.a.  a  rapoelcory  of  unstructured  decs  implamcntic  tha  tradi¬ 
tional  UHIX  "file"  concept; 

-  a  sac  of  attribute*  chat  are  primitive  value*  which  csn’be  named  individually; 
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*  a  set  of  relationships  la  which  the  object  participates. 


UlirioMhtjw  allow  tha  representation  of  logical  associations/ depeodeacea 
between  objects  as  wall  as  structured  information.  la  particular,  oaa  might  aaad 
to'  Introduce  naw  compound  objacta,  composed  of  saveral  objacta  (a  motion  that 
supercedes  tha  traditional  directory),  or  to  aatabliah  explicitly  a  rcfaraaca  freai 
on  a  object  to  another.  Kalatioacbipa  also  map  have  attributes,  which  cao  ha  used 
to  daaerlba  a  pacific  propartiaa  aaoociatad  with  tha  relationship,  and  which  allow 
tha  designation  of  a  apacific  ralatloaahip  (among  tha  possibly  many  la  which  a 
given  object  nay  participate)  by  tha  values  of  ita  (kay)  attributes. 

Designation  of  ralatiooahipa  la  tha  baaia  for  tha  designation  of  objacta?  tha 
principal  aaana  for  accaaaiag  objacta  in  noat  OHS  oparatloaa  ia  to  navigate  tha 
OMS  objact  apaca  by  "traversing*  a  sequence  of  ralatiooahipa  designated  by  a 
atring  value  type  pathname.  Tha  ayntax  induced  by  tha  OMS  on  auch  atringa  la  (of 
couraa)  compatible  with  the  ayntax  of  OKU  pathnames. 

Objacta  and  relationship!  have  a  type  which  daflata  thalr  basic  propartiaa. 
Object,  attribute  and  relationship  type  definitions  sra  contained,  in  special 
objects  of  tha  pradefinad  type  Schema  Definition  Sat  (SDS).  SI'S  a  can  be  specific 
to  Individual  osars  and/or  tools  or  be  common  to  a  community  (of  users  or  tools). 

it  any  time ,  a  process  operates  with  a  see  of  visible  definitions,  that  con¬ 
stitute  its  working  schema.  Tha  working  schema  ia  established  for  a  process  os 
tha  well— formed  composition  of  a  sat  of  SDS  a  aad  can  be  dynamically  ra-eatablished 
ao  as  to  change  tha  working  context  of  a  process.  1  working  schema  corresponds  to 
a  description  of  cartain  constraints  on  tha  propartiaa  of  a  collection  of  objacta 
and  of  relationships  which  are  operated  by  a  given  process.  A.  working  schema  can 

a*...*  am*  fthm  mmmm4  mf  bd  mm  e  4  as  (man  uknfi  apn^£mJ  Ja  fKm  •  DTuj 

relationships  specific  to  a  given  osar. 

Thus,  different  user*  and  tools  may  operate  with  different  working  schemas, 
though  accessing  tha  same  object,  resulting  ia  tha  facility  to  particularism  the 
way  in  which  an  object  la  'seen*. 

These  mechanisms  resemble  la  many  ways  to  a  full-fledged  DBMS,  with  soma  sig¬ 
nificant  differences; 

—  The  goal  of  tha  system  ia  not  to  make  complex  computations  with  tha  valuta  of 
tha  ectrlbutec  that  are  associated  with  an  object;  the  major  part  of  tha  compu¬ 
tation  will  ha  par fora ad  on  tha  objact  contents,  whose  details  are  administered 
by  tha  tools. 

-  The  osar  must  have  tha  possibility  to  use  tha  system  for  his  own  needs,  and  to 
modify  Its  working  contact  by  tha  definition  of  new  objact  aad  relationship 
types,  without  having  to  go  to  i  higher  authority. 


3.5.  Activities 

Tha  lack  of  data  access  synchronisation  end  recovery  mechanisms  is  one  of  the 
recognised  deficiencies  of  UNIX  like  environments.  It  Is  overcome  in  FCTE  by 
adapting  tha  wall  known  notion  of  transaction  to  tha  context  of  Software  Engineer¬ 
ing  Environments.  In  a  general  Sanaa,  e  transaction  can  be  regarded  ea  a  work- 
frame  in  which  individual  operations  taka  place.  A  transection  can  ha  defined  to 
have  cartain  propartiaa,  namely 

-  It  ia  atonic,  tha  affect  on  data  of  operations  performed  on  behalf  of  e  tran¬ 
saction  la  aither  applied  aa  a  whole  or  ia  not  applied . 
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•  ic  la  aarlallaable.  cha  alia eta  o f  executing  several  transactions  to  operate  oo 
tbh  iu<  data  domain  at  tha  ‘tut'  tla«  ara  expected  to  be  tho  am  *a  if  Cha 
aaaa  transactions  were  executed  la  autual  exclusion. 

In  KTl ,  tba  concept  of  transaction  la  generalised  to  tba  concapt  af  m Activity' . 

Ona  la portant  and  dlstingulslng  aapact  which  la  daalt  with  by  FCTE  Activities 
la  the  concapt  of  “ granularity*  of  tools,  which  naana  regarding  aach  tool  (althar 
program,  script  or  prograa  fragment)  aa  a  nodular  component,  performing  a  wall 
daflsad  (hopafully  atonic)  function.  Mora  powerful  toola  can  ba  assembled  out  of 
tlaplar  onac;  tba  now  tool  can  bacoata  ltaalf  a  new  grain  participating  in  tha  con¬ 
st  ruction  of  othar  toola. 

Each  tool  can  ba  rtgardad  aa  a  primitive;  functional  layara  can  In  thla  way 
ba  built  out  of  tool  aata.  Tha  failura  of  ona  of  tba  tools  nay  or  nay  not  ba 
lntarprttsd  aa  a  coaplata  failura  dapandlng  on  tha  context  in  which  It  vaa 
invoked.  Tha  natural  solution  is  to  allow  for  nesting  of  Activities.  In  a  way 
similar  to  tha  dynamic  flrat-in-lact-out  management  of  tha  local  context  of  blocks 
and  procadurca  In  modern  programming  languages.  Thus,  PCTT  Activities  can  ba 
nastad;  tha  basic  PCTE  fadlltlaa  support  a  coaplata  and  conaintant  nodal  featut— 
lng  implicit  aa  wall  aa  explicit  racovary  and  synchronisation  nachanlana  (locks) 
which  fully  support  tha  atomicity  and  aarlallaabllity  raquiroaents.  Furthermore, 
Activity  types  and  object  laval  oparatlons  ara  sup port  ad  which  allow  tha  tool 
writer  to  tuna  tba  mechanisms  to  tha  dasirad  laval  of  data  conaiatancy  and  con¬ 
currency  control,  ranging  froa  the  UHXZ  Ilka  "unprotected”  behavlout  to  proper, 
fully  protactad  atonic  and  aarlallsabla  "transactions". 

Actlvltlaa  ara  naant  to  support  In  a  systematic  and  standard  way  the  con¬ 
struction  of  robust  tools. 


A.  The  Usar  Interface 


4.1.  Introduction 

Tho  design  rf  a  Osar  Interface  Is  becoming  more  and  nor  a  Important  along  with 
tha  development  rf  hardware  being  able  to  drive  graphic  output.  Tha  availability 
of  workstation  computer*  with  a  high  resolution  raster  screen  and  a  pointing  dor¬ 
ies  (e.g.  a  mouse)  makes  It  possible  to  develop  interfaces  that  at  least  have  Cha 
feature  to  produce  near  friendly  output  instead  of  plain  text.  This  paper  talks 
about  tho  basics  chat  a  Osar  Interface  should  provide  in  general,  using  cha 
resources  of  the  computer  in  a  sound  way.  It  la  ucc  concerned  with  a  discussion  of 
tha  conceptual  power  that  a  Osar  Interfaca  nay  tmploy  [Z j [4} .  riany  principles,  of 
course,  rmaaln  tho  asms. 

Since  FCTE  concepts  ara  based  on  codarn  operating  systems,  several  a  plica¬ 
tions  may  ran  In  parallel.  All  of  them  say  require  interaction  with  tha  usar.  The 
User  Interface  provides  the  user  with  a  communication  port  to  the  different  appli¬ 
cations  In  the  osar's  working  configuration,  Interprets  osar  input,  and  chaunala 
It  to  cha  corresponding  applications.  This  i>  supported  by  dividing  tha  visible 
scraan  Into  savers!  rectangular  areas  called  windows,  vharaby  each  window  nay 
serve  a a  an  output  cadis  for  aa  application,  and  by  providing  powerful  comaunica- 
tion  cachauiaca  for  application  Interaction. 


4.2.  Aa  object  oriented  Dear  Interfaca 

Tha  User  Interface  will  work  in  an  object  oriented  way.  Tha  objects  formed  by 
the  Osar  Interfaca  ara  windows,  icons,  or  the  elements  of  different  datatypes  such 
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ii  characters,  strings,  graphical  elements,  ate.  Tha  basic  Interaction  a ode  la 
represented  by  first  selecting  an  objaet  and  aacond  performing  an  operation  on  eha 
■elected  object.  For  instance,  the  oaer  may  aeleet  any  object  currently  visible  In 
any  window  on  the  screen,  apecify  tha  deatination  (which  doaa  not  hare  to  be  tha 
aama  window)  and  Issue  tha  generic  copy-eommamd .  The  Oaer  Interface  generates 
information  about  tha  type  of  the  selection  and  hence  it  la  able  to  determine 
which  specific  actions  ara  required  to  perform  the  generic  copy. 

This  principle  in  extended  from  the  idea  of  object  oriented  programming  (1]. 
However,  the  Oaer  Interface  is  based  neither  on  such  e  programming  language  nor  an 
objaet  orlentad  operating  eyatom.  It  is  tha  method  of  oaer  interaction  which  la 
objaet  oriented,  it  this  point  it  should  be  stated  that  tha  objects  formed  by  the 
Deer  Interface  ere  sat  menegod  by  Che  PCTE  Object  Management  System.  In  feet, 
objecca  within  the  Oser  Interface  ere  dynamic  data  structures,  which  ere  managed 
locally. 

The  Cecr  Interface  provides  the  standard  functionality  of  a  window  management 
system.  Windows  can  be  thought  of  as  piacss  of  paper  arranged  on  a  desk.  Windows 
can  be  moved  around  on  a  desk.  Windows  may  overlap  or  overlay  on  the  screen  to 
utilise  the  screen  optimally  by  biding  non  relevant  information.  Every  application 
can  be  accessed  by  the  user  via  its  associated  windows.  It  la  the  responsibility 
of  the  Osar 

lnpue  to  an  application  can  be  achieved  from  the  uaer  point  of  view  either  by 
input  from  the  keyboard,  pointing  device,  or  by  copying  any  selected  Item. 

It  le  also  posaible  to  raplaca  a  window  by  a  smell  placeholder,  the  icon, 
which  Indicates  to  the  uaer  that  a  running  application  has  no  window  for  its  phy¬ 
sical  repraaantation.  In  this  case  the  output  of  tha  application  la  not  visual¬ 
ized.  Icons  permit  tha  saving  of '  screen  specs  ter  running  or  waiting  applications 
and  allow  easy  re-activation  mechanises  for  communication  to  the  uaer.  They  may 
alao  be  used  to  provide  an  iconic  interface,  aa  for  Instance  in  the  Star  system 
13]. 


Applications  run  independently  of  one  another  end  ere  able  to  communicate 
with  each  other  at  a  low  level  by  passing  massages.  PCTE  Is  based  on  the  low  level 
message  passing  system  am  It  is  described  In  PCTX  basic  Mechanisms.  Based  on  the 
active  role,  tha  entities  of  tho  Deer  Interface  ere  classified  as: 

-  Deer  Agent 

-  Applications. 

Figure  1  Illustrates  the  basic  structure  of  tbe  Dear  Interface  model.  The 
Doer  Agent  le  In  charge  of  translating  the  intentions  of  tha  user  to  tha  syataa. 
Ita  functionalities  cover  tha  display  and  tha  management  of  windows,  tha  control 
of  Input  from  various  input  devices  and  eha  management  of  commands  and  nanus.  Tha 
most  important  wrk  however  la  tha  aynchronisation  within  tha  Osar  Interface. 

Applications  rapraaant  tools  to  eha  User.  Existing  tools  will  use  an  0S- 
Applleeelon,  emulating  the  host  operating  eystem  in  a  window  working  In  a  standard 
terminal  mode. 
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figure  1  Buie  Sense  cm*  of  the  Dear  Interface 


These  cools  may  chan  ba  need  within  CUa  Usar  Interface  without,  any  changes. 
However,  they  will  In  general  not  ba  mb  la  to  make  uaa  of  Cba  advanced  functionali¬ 
ties  offarad  in  cha  User  lacarfaca. 


4.3-  DSU  wanna  FCTE 

Tha  first  approach  to  ixplaaenr.  PCTE  la  to  tabs  UBIX  at  a  basis.  It  is  obvi¬ 
ous  that  aoat  existing  08 IX  tools  for  alphanumeric  displays  do  not  know  about  win¬ 
dowing  aystasa,  object  orlaatad  handling ,  ate.  It  would  ba  a  major  task  to  convert 
them  all.  Instead  a  0H1X  TT7  emulation  must  ba  availahla.  This  ovulation  provides 
ona  window  for  character  input  aztd  output,  having  tha  behaviour  of  a  standard 
alphanumeric  terminal.  In  addition,  this  TTY  emulation  allows  tha  user  to  select 
text  displayed  within  tha  window.  Thus  It  la  possible  to  copy  text  from  tha  TTY 
window  to  any  otbsr  tool.  In  the  same  uasnar,  tha  user  may  ptrforn  free  editing  of 
tha  entrant  demand  input  Una. 

The  exploitation  of  tha  Use?  Interface  will  ba  dona  by  new  tools  to  bs 
developed  especially  for  this  environment.  It  should  ba  noted  r.hst  sc  present  many 
vendors  already  offer  windowing  facilities  and  enhanced  graphic  output  for  UNIX. 
Moat  of  them  have  developed  highly  sophisticated  tools,  such  ss  display  oriented 
text  editors,  doctmant  preparation  sysecs*,  font  editors.  Interactive  program 
envlromsnts  ate.  However  moat  of  them  are  written  specifically  for  the  gives 
workstation.  It  la  obvious  that  these  tools  are  sot  portable  et  all  and  bancs  can¬ 
not  run  In  cha  FCTE  environment. 
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l-K-  The  User  Interface  from  the  user 's  poise  ei  view 

We  have  CO  separata  tha  PCTE  nears  loco  eve  groups:  one  consisting  of  users 
working  with  cool*  (a.g.  editing  a  detriment,  printing  sail,  ace.)  and  tha  other 
consisting  of  tool  writer*.  Their  task  la  eh*  development  cod  ImpleMaceatlon  of 
sew  tools.  They  work,  with  cha  primitives  provided  fer  pregruaMra  as  th*y  are 
described  la  the  functional  specification  of  PCTE.  This  paper  la  concerned  with 
tha  first  (roup. 

When  initialising  the  Qaar  Interface  of  PCTE,  the  screen  will  bo  presented  ee 
en  empty  grey  area.  If  tha  Osar  la  not  already  logged  into  the  system,  ha  will  ha 
requested  to  do  so  first.  This  task  1«  controlled  by  e  new  login  tool,  running 
with  a  special  login  window.  Any  user  nay  request  «  cusuod  script  to  run  after 
Identification. 

This  method  allows  the  generation  of  a  specific  cool  environment  to  he  ini¬ 
tialized  for  each  login  identification.  A  discussion  on  coons  nd  scripts  follows  In 
the  chapter  of  "command  language*  . 

The  Interaction  between  the  User  Interface  end  the  user  eey  be  cleaslfled  as 
follows : 

-  Tool  M&aegeaent 

-  Window  Management 

-  Seale  Editing 


4.4.1.  Tool  Management 

Once  a  UNIX  shall  la  running,  tha  user  will  find  himself  In  tha  standard  UNIX 
envirorsreac.  Bo  special  support  Is  given  as  long  as  he  is  not  using  any  of  the 
tools  specifically  written  for  PCTE. 

«e 

Any  new  tool  normally  scarce  up  by  creating  it's  own  window  (or  set  of  win¬ 
dows)  providing  a  maw  working  ssvlromaat.  Tha  behaviour,  of  course,  Is  determined 
by  che  characteristics  of  tha  tool  . 

,  The  User  Agent  provides  facilities  to  allow  the  execution  of  tools  without 
: having  to  run  s  shell.  The  profile  for  my  user  gay  defies  cools  that  ssay  be 
started  directly.  Selecting  one  of  these  tools  by  name  from  a  system  defined  menu 
will  result  In  starting  the  tool.  Turtbcr  control  is  done  by  PCTE  primitive*  or  by 
a  special  PCTE  process  manager. 


1.3.  Window  Management 

Window*  ere  Uaar  Interface  objects.  They  say  react  to  any  generic  coasand  the 
user  may  have  initiated.  The  communication  b*tvmen  tha  tools  end  the  User  Agent  Is 
achieved  by  sending  mtasages.  Each  command  generated  results  in  s  message  sent  to 
to  tbs  appropriate  tool,  which  is  In  charge  of  tha  object. 

figure  2  shows  en  example  of  the  move  eeamacd  -  The  advantage  of  this  concept 
la  that  any  cool  may  control  any  operation  the  user  Initiates  and  check  for  con¬ 
straint*  (a.g.  don't  move  a  window  so  chat  it  hides  relevant  parts  tic  the  screen. 
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Tlgura  2  An  example  of  the  novo  command 


Examples  of  operations  on  which  windows  «at  react  are: 

-  Create  Vlndou 

A  Cool  U7  cienca  •  window  on  «a  olroad y  existing  dots  oCructuco.  Depending  on 
the  characteristics  required,  tho  size  and  position  may  b«  requested  Interne” 
tlvsly  or  mey  bo  predefined.  It  Is  important  to  cots,  that  a  user  should  not  be 
able  to  create  a  window  explicitly  to  starr  a  tool.  The  end  user  should  oaly 
start  ths  cool.  It  is  tha  responsibility  of  tha  tool  to  determine  If  a  window 
la  necessary.  Is  this  manner  tha  tool  la  able  to  place  a  window  le  necessary  at 
a  predefined  position  or  ask  the  user  Co  specify  the  location  or  tbs  alsa.  In 
contras c,  a  tool  nay  start  as  being  represented  by  an  icon  only. 

-  Iconise  Window 

An  open  window  will  be  replaced  by  a  spaciflad  Icon  at  a  position  which  la 
defined  by  the  near  un  the  screen.  Icons  say  be  wowed  and  bidden  on  the  screen 
Ilka  windows. 

-*  Expending  an  Iconized  Window 

An  icon  is  exparled  to  s  window  with  tha  sans  characteristics  as  before  Iconis¬ 
ing  (however,  a  change  of  position  and  alsa  say  be  employed).  Tha  contents  of 
tha  window  are  updated  according  to  tha  viewport,  reflecting  any  changes  Chat 
nay  have  occurred  while  ths  window  was  Iconised. 

-  Additional  Operations 

In  addition,  all  standard  window  naoagsatac  operations,  such  as  deists,  wove, 
bury,  etc  are  supported. 

Evan  when  a  window  is  Iconizad,  it  say  still  be  sensitive  to  Messages.  Tor 
Instance,  a  'fils  directory  icon*  say  b«  responding  Co  an  Insert  command  with  the 
arguatant  being  suet  bar  'file  Icon* .  Expanding  such  a  "fils  Icon*  may_  invoke  Che 
text  document  preparation  system  on  this  fils.  Tills  enables  tha  creation  of  a  User 
Interface  environment  in  s  astmsr  which  Is  commonly  used  In  office  automation  sys¬ 
tems  [3]. 


4.3.1.  Stale  editing 


Sasic  editing  la  provided  to  allow  simple  and  as sy  modification  of  objects 
vla-ibla  on  ths  acracn.  Strictly  speaking,  window  management  la  pert  Stale  editing. 
Moving  a  window  on  tbs  screen  la  essentially  cot  different  from  moving  a  character 
fro*  one  petition  to  another.  This  section,  however  describes  Cha  facilities  pro¬ 
vided  for  the  management  of  objects  independent  of  their  data  typts 

-  Selection  of  as  object 

Simple  selection  li  defined  for  each  rypa  by  default.  It  nay  be  replaced  by 
sore  powerful  selection  functionalities  In  special  tools  as  needed.  The 
•elected  ebjocts  will  be  highlighted  to  visualize  the  eelectlon  to  the  near. 
There  are  three  kinds  of  Interaction: 

-  start  selection 

A  new  selection  will  be  defined.  If  an  object  la  already  selected,  it  will 
flrac  be  deeelected.  The  position  of  cha  cursor  determines  tbr  new  object  to 
be  eelected.  There  is  only  one  selected  object  la  the  eytea.  ht  the  time  the 
object  la  identified,  it  suit  also  be  visible  on  the  acrean. 

-  multi-click  selection 

Freising  the  start  selection  button  within  an  already  selected  ltan  will 
Increase  the  selection  level.  For  ins  cane  a,  a  syntax  oriented  editor  may 
identify  each  level  with  a  production  in  the  underlying  grammar.  On  the 
other  hand,  sulci- click  selection  la  not  defined  for  ordinary  windows. 

-  Extend  selection 

The  currant  selection  will  be  extended  to  the  poeition  of  the  cursor  at  the 
current  selection  level.  For  instance,  if  e  line  is  the  current  selection 
and  Cha  user  pr eases  the  extend  selection  button  on  the  next  line,  then 
these  two  lines  are  eelected.  For  graphics  etc,  the  extend  selection  may 
•pawn  a  rsctsngle  to  include  all  objeeta  inside  the  rectangle  for  selection. 

-  Copy  Selection 

Ths  concents  of  the  current  selection  will  be  inserted  according  to  ths  defini¬ 
tion  at  the  insertion  position.  Type  conversion  of  objects  (e.g.  copy  from  a 
simple  text  frfeso  to  a  complex  text)  Is  applied  If  it  is  appropriate.  Ths  copy 
of  the  objects  window  oed  Icon  is  «cf  supported. 

-  Delete  Selection  ' 

The  contents  of  the  selection  will  be  deleted,  ths  selection  itself  will  be 
deleted,  too,  since  it  is  no  longer  neanlnful. 

-  Movo  Selection 

This  functionality  is  e  combination  of  Copy  Selection  end  Delete  Selection. 
However,  for  certain  objscts  (such  as  window,  ecc)  the  operation  will  be  p ve¬ 
to  rued  directly. 
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A. 5. 2.  Th*  current  window 

Even  though  many  tools  nay  run  Is  parallel  within  PCTE,  that*  is  00X7  one 
keyboard  and  ona  locator  Input  device  for  all  of  then.  Tha  sharing  of  thasa  input 
devlcea  iff  mandatory.  Tha  basic  Interaction  for  tha  uaar  is  as  fellows:  ha  will 
have  to  aalaet  tha  object  window  (and  banco  tha  corresponding  tool)  and  issue  tha 
‘keyboard  pressed*  cnanand  at  tha  tine  a  press  on  tha  keyboard  is  perfomed.  Even 
though  this  technique  seers  to  fit  Into  tha  nodal.  It  is  sonewhat  unnatural  and 
nakes  certain  kinds  of  interaction  slow.  For  Instance,  to  copty  a  string  ffron  one 
placa  to  soother,  tha  uaar  will  haws  to  psrfora  tha  sslectlon  of  tha  string  first. 
Sines  tbsre  nay  ba  only  one  selactad  object  in  tbs  User  Interface,  any  possibly 
selected  window  will  be  deselected  first.  After  Issuing  the  copy  coaaand,  a  desti¬ 
nation  position  has  to  ba  specified.  Whan  the  copy  is  caaplsts,  there  are  two 
choices:  either  the  selected  string  resales  selected  or  le  will  bo  dssalectsd.  In 
any  csss,  to  continue  with  normal  data  input,  a  window  has  to  be  reeeleeted.  Any 
task  will  be  slowed  down  heavily  by  the  repented  reselection  of  windows  after 
issuing  a  generic  eonaand. 

The  solution  Is  to  define  e  current  window  independent  of  tha  selactad  win¬ 
dow.  A  window  will  remain  current  unless  it  is  destroyed  or  another  window  is 
defined  to  ba  current.  Any  character  Input  will  ba  read  by  the  currant  window, 
Independent  of  the  selected  object.  This  enables  tha  uaar  to  type  Into  ana  window 
and  ass  genetic  commands  for  eny  kind  of  objects  at  tha  same  tine. 

In  this  respect,  the  tool  haring  tha  current  window  la  said  to  be  the  currant 

c<  61. 
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It  has  bean  deaonstrstad  that  the  Osar  Interface  nay  work  directly  by  user 
control  of  certain  peripheral  devices.  For  Instance,  pressing  a  certain  button  on 
the  nouns  nay  select  as  object  on  the  screes .  Any  following  cenaand  will  than  ba 
sent  to  the  tool  Managing  tha  conns  nd. 

This  chapter  talks  about  bow  conaands  nay  be  entered  and  how  tools  will  reed 

then. 


The  User  Interface  defines  several  Input  cissies.  The  noat  important  eve: 

-  larboard: 

Conventional  character  data  input  nay  be  rsad  within  this  class. 

*  locator: 

This  class  provides  a  aachsaisa  to  rsad  positions  on  tha  screen,  either  in 
screen  coordinacas  or  (which  is  useful!  for  tools)  In  vindev  coordinates.  This 
input  la  typically  provided  by  a  nouse. 

-  naaaage: 

This  class  is  used  for  caooRK&lcatlon  between  a  tool  end  the  User  Agent.  Ele- 
nents  la  this  class  ars  generated  by  tha  User  Agent.  Tha  teal;  of  genst'stins 
sassage  usually  depends  on  input  from  the  classws  keyboard  and  locator. 

Tha  User  Agent  has  to  deteraina  if  the  Input  fron  keyboard  and  locator  class  is 
to  be  pasted  through  to  e  tool  directly  v  r  if  it  has  to  ba  Interpreted  to  fora 
a  nasasga.  Figure  3  shows  tha  flow  of  data. 
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input  dau  keyboard 

User  Agent 

_ _ _ 

i 

keyboard 

input  dau  locator 

7 

r\ 

locator 

input  dau  massage 

■  ? 

interpreter 

figure  3  Input  data  flow 


Tha  interpreter  within  the  Uaar  Agent  determines  the  behaviour  of  tha  Otar 
Interface.  This  behaviour  of  courts  la  fixed  and  cannot  be  altered .  In  addition, 
It  la  not  possible  to  enter  any  r.aaaand  in  taxt  fora.  To  got  around  thia  problaa  a 
coaaand  language  lntarpratar  nay  ba  ina tailed  aa  an  application,  this  command 
language  application  nay  read  fraw  the  Uaar  Agent  in  tha  keyboard  claaa,  paraa  tha 
input  aud  ganarata  output  in  any  other  claaa  to  be  sens  to  tha  Uaar  Agent  for  dir* 
trlbutlon  to  another  tool,  figure  A  llluotratae  tha  aat  up. 


keyboard  keyboard 


figure  A  Input  data  flow 

Thia  technique  allowa  tha  lapleaentaelon  of  uaar  tailored  command  language 
tool*  and  enables  secy  feature*: 

*  produce  a  history  list  of  contends  in  a  uaer  readable  format, 

-  provide  for  execution  of  coanaod  scripts, 
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allow  easy  control  of  one  cool  by  another  tool, 

provide  aa  interactive,  interpretative  environment  for  Ueer  Interface  issues 


5.  Distribution  la  PCTI 

The  fCTE  preferred  arehltactura  la  a  local  Area  Network  of  powarfol  single- 
user  workstations  cad  aaaoclaced  resources.  la  this  e«viro«**ot  project  tame*  and 
uaara  share  aafcvara,  data,  and  peripheral*.  Tbla  whole  arehltactura  la  aaau  by 
the  sear  aa  a  single  aachlaa  and  yet  each  aaehlnn  can  act  aa  autonomous  unit* 

All  vorkacaclona  In  the  environment  here  equal  rlghta.  Suceaaaful  operation 
of  the  Dlatrlbudon  mechanism  doea  not  depend  upon  any  hierarchy,  fixed  or  confi¬ 
gurable,  of  the  vorkecationji  or  of  the  underlying  LAM,  Nor  la  the  ability  of  a 
process  to  aake  a  requeat  of  e  remote  kernel  altered  or  diminished  by  changes  in 
the  LAN  topology. 

The  Distribution  mechanism  provides: 

-  Trane parent  distribution  of  the  functions  of  tha  OMS,  proceae  execution,  pro¬ 
cess  structure  and  later  proceae  communications. 

-  Network  Administration  lc,  control  aenegcaent  of  tha  communications  layer, 
namely  tha  OS1  Transport . 

-  Distribution  Management,  is.  control  end  configuration  of  the  distribution 
Etthsslss  itself. 


3,1,  Process  Distribution 

The  transparency  of  distribution  impose*  a  generalised  access  to  various 
processes  running  In  tha  system.  A  process  la  characterised  In  PCTE  by  It*  exe- 
•  cutabla  code.  Its  data  and  a  collection  of  Information  constituting  Its  'execution 
context*  and  ie  miquely  identified  by  Its  aystoarwld*  proeess_id. 

No  process  may  mlgrata  from  tha  workstation  en  which  it  was  created,  but  this 
la  v>  limitation  on  its  ability  to  accasa  reaote  resources.  The  Distribution 
mechanism  allows  a  process  to  ereate  child  processes  on  othar  workstations,  eithar 
deliberately  (by  explicitly  quoting  the  desired  st*tion_id)  or  implicitly,  accord¬ 
ing  cd  tbs  characteristic*  of  the  child  itself,  such  as  Its  specific  hardware 
requirements. 

Similarly,  when  accessing  OMS  objects,  the  process  need  not  be  sware  of  the 
physical  locations  of  theaa  objects.  Tha  Distribution  aschanlsm  shields  the  pro¬ 
cess  from  being  dependent  upon  topological  considerations. 


3,2.  Objects  Distribution 

Tha  QMS  database  lo  partitioned  into  volumes,  which  correspond  to  logical 
disk*  (equlvelant  tc  the  notion  of  File  Systmi  In  0N1X).  Each  volume  is 
represented  by  a  specially  typed  OMS  object.  In  principle  (hardware  permitting), 
each  volume  can  be  dynamically  allocated  ('mounted*)  tc  e  particular  workstation. 
On  Bouncing,  a  volume  la  immediately  visible  to  the  whole  -  of  the  system  at  in 
Locus  {8],  The  distributed  database  Is  managed  by  the  statie  and  dynamic  manage¬ 
ment  of  volumes:  statically  by  their  creation  end  deletion  in  the  OMS,  dynamically 
by  the  mounting  and  unmounting  of  a  volume. 
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La  eh  workstation  1*  considered  •  potential  server  to  the  achat  workstations 
fas:  cha  portion  of  tha  abject  base  which  ia  contained  on  volumes  "mounted*  at  that 
workstation.  talatlcnahips  can  exist  between  objecta  contained  on  different 
▼oliaea.  Access  to  objects  on  a  sconced  volume  is  wade  by  navigating  through  a 
sequence  of  links,  originating  from  one  of  the  process's  reference  nodes.  It  ia 
the  responsibility  of  tbs  distribution  software  in  association  with  QMS  to  provide 
aecees  to  every  object  available  to  each  particular  user,  both  in  locating  where 
it  resides  and  in  providing  the  remote  access  methods-  Actions  performed  on 
remote  objects  should  appear  to  tha  user  in  every  respace  to  have  the  awe  effect 
ae  if  applied  to  e  local  object. 

There  is  no  need  in  PCTE  for  ehe  concept  of  e  ayoten  wide  "super-root"  as  in 
tha  Mewceatla  Connection  [9],  or  of  "epecial  network  files"  acting  as  local  dum¬ 
mies  for  remote  coots  as  in  Cec&nst  [10]. 


5.3.  Distribution  of  Activities 

The  concurrency  end  integrity  control  facility  of  PCTE  (Activities)  also 
operates  in  a  distributed  context.  System  wide  identification  of  activity  con- 
terra,  management  of  voltaa  level  logging  a*  well  ae  the  distributed  termination 
of  activities  (two  phase  commit/ roll-back  protocol)  ere  supported  by  the  distri¬ 
bution  mechanism.  ’ 


5.4.  Inter  Process  Communication 

Am  e  process  structure  becomes  distributed  so  nay  Its  moans  of  later  Ptocsss 
CoessunieBtion  (I PC) .  All  tone  of  Ire  supported  by  PCi tn  basic  mechanises  may  be 
distributed  that  Is  named  end  unnamed  pipes,  maned  end  unnamed  message  queue*. 

Hamad  pipes  end  mjw4  massage  queues  ere  special  OKS  objects  sod  consequently 
are  managed  ms  such.  Utuumad  pipes  and  message  queues  became  distributed  by  the 
creation  of  a  distributed  process  structure.  A  user  need  not  be  aware,  by  use, 
that  IPC  la  distributed. 


5.5.  letvork.  management 

Each  workstation  ia  rspresemted  by  an  object  in  the  database,  sod  Is  also 
identified  in  a  globally  unique  any  by  the  identification  number  (host_ld) .  This 
Bomber  la  assigned  when  the  work  station  Is  initially  created.  All  PCTE  primi¬ 
tives  that  elrcwveut  the  transparency  of  the  distributed  system  cake  explicit  use 
of  tha  hoet_ld. 

The  Distribution  mechanlaw  has  to  nonage  the  static  topology  of  workstations 
ms  well  as  the  connection  end  disconnection  of  workstations  from  the  system. 

The  Distribution  mechanic®  itself  requires  configuration  and  management,  in 
order  that  it  nay  act  aa  efficiently  m*  possible  in  particular  installation* ,  and 
that  it  nay  bid*  tha  installation' a  physical  topology  and  provide  sn  Invisible 
earvlee.  This  iuforaatlon  has  to  be  maintained  in  a  replicated  torn  on  all 
workstations  cs  each  station  is  to  be  permitted  to  fraction  autonomously. 


5.4.  Dorking  is  the  distributed  PCTE. 

This  section  describes  what  a  user  sees  of  tha  envlrossent  on  connecting  to  e 
PCTE. 
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A  user  la  known  by  hla  neur ,  password,  identity  ami  grout  nun  bar ,  Me  tof  tr¬ 
ance  object*  (eg.  Initial  hor>c  working  directory)  and  hie  Initial  Working  Schema. 
The  p*« •  word  file  contain*  £>//>  details  of  each  recognised  eaer. 

the  Newcastle  Connection  maps  between  distinct  pnstp.iurd  files  located  on  dli- 
farant  Machines,  vhsrear;  Uv.ua  Mlntalns  In  an  automatic  way  ’logical  file  groups* 
that  art  to  b*  found  ropllcatvl  throughout  the  etriromeot  an  “physical  file 
groups'.  Our  design  follow  Mrs  closely  the  approach  of  Locus:  unlike  the  Hawea*- 
tle  Connection,  in  PCTE  a  uaar  has  e  single  entry  in  e  password  file  which  la  com¬ 
mon  to  all  workstation#.  This  approach  aakaa  iha  etetlon*  a  tier  sable,  and  conse¬ 
quently  any  known  uaer  nay  work  os  any  of  tha  connected  workstations. 

After  etsrt  up  and  cosmaccin/;  a  workstation  to  a  PCffi  to  which  ho  balongs  a 
vorkacatlon  user  can  acres*,  in  a  totally  unlfon  way,  all  the  resource*  of  the 
entire  envlroment  (software,  hardware  and  objects  found  on  noun  cad  voluncs)  to 
which  he  la  entitled  a*  if  thny  wore  on  his  own  workstation.  This  fairly  obvious 
•teteaent  does  have  import-lot  iapLlraclona  both  In  the  philosophy  of  whet  PCTE 
exactly  1*  end  In  tha  ln/ienaatatlon  strategy  chosen:  e  PCTE  it  not  a  community  of 
eeperate  coominicad.ng  c<w?u tars  «»  in  tha  Sawcaatla  Connection.  Tha  binding 
within  PCTE  la  coneid  it.ahly  ti  fitter.  Member  of  the  PCTE  community  are  unaware  of 
tha  communication  betvr.e'j  .hr/  and  (here  such  entitles  es  password  end  group 
files,  es  they  do  with  vll  c?»  tea  admins  cratiovs  i&lo  motion.  Information,  with  few 
exceptions,  la  distributed  throughout  V.ha  environment. 

There  la  no  hlarr.rr.hy  of  wuv'cr melons  Implied  in  the  structure.  A  workstation 
need  only  have  access  rx  uiffiriant  syttem  edmlnistretlon  information  to  anabla  it 
to  work  (la  isolation  or  wthewiea).. 


3.7.  Architecture  tf  the  Watrl’flaticn  mechanism. 

The  PCTE  kerne-  is  built  on  top  of  the  UNIX  kernel.  The  Implmsentetlon  of  the 
distributed  envlr or/jr pt  doe,*  not  depend  on  a  distributed  version  of  tha  kernel, 
but  on  the  presence  <A  f/'.‘llitias  for  Che  construction  of  a  systsa  of  communicat¬ 
ing  kernels.  The  7)tot rihjtion  necbenlsn  is  pert  of  the  kernel ,  end  es  such  exists 
on  eech  workstation;  in  this  sanso  Che  system  corresponds  to  the  Newcastle  Connec¬ 
tion  (9]. 

Processes  oat  roots  resources  by  mean*  of  s  neatat-elava  process  pair,  es  In 
Locos  rather  then  the  Newcastle  Connection.  Internal  communication  at  the  level 
of  kernels  (IRC)  la  handled  by  e  formal,  styllsad  lanote  Procadura  Call  (RPC) 
scchcniK.  TMt  SJPC  mechanism  relies  ou  a  terries  providing  both  connected  end 
counoctlonleae  transport  facilities  (supplied  from  tbs  Esprit  ROSE  [5]  project). 

A  PCTE  system  is  essentially  restricted  to  a  LAG.  The  LAN  development  has 
bean  simplified  by  making  cartels  eaauaptlons: 

-  t*zml<"Ls  are  only  attached  to  PCTE  vie  a  PCTE  workstation.  An  exception  to 
this  may  be  target  computers  attached  to  the  LAN  for  embedded  system  develop¬ 
ment. 

-  every  workstation  suet  provide  an  Implementation  of  ISO  OSI  layers  1  and  2 
for  CbKA-CD. 

-  tha  ROSE  (Esmarch  into  Opau  Systems  for  Europe)  project  will  provide  an 
Implemeutatiuo  of  OSI  Transport  Service  end  Pr or ocol( class  4)  conforming  to 
ISO  DISBQ7?  and  DIS8073  and  a  Connectionless  Transport  Layer  conforming  to 
emerging  ISO  standards. 

Tha  Ptecributlon  nechenlea  it  being  designed  end  inpleaented  In  line  with  present 
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and  «««rgin*  ISO  Standard*,  and  will  use  EOSE  Transport  for  ail  IAN  access. 


3.8.  fCTE  Catoway 

So  far  we  have  described  only  the  mechanism  Char  binds  all  the  aeparata 
workstations  into  a  tingle  wait,  a  PCTE ,  but  sot  described  how  a  PCTE  nay  comaunl- 
cata  to  another  system  or  PCTE. 

A  PCTE  gateway  la  a  software  mechanism  that  can  be  configured  to  coaaunlcata 
at  a  particular  logleal  level,  through  a  known  conaunicatloa  device,  to  a  known 
recipient.  In  this  connection,  gateway  funetlona  make  available  to  tha  ueer  tha 
Saealon  and  Presentation  layer  of  tha  ISO  nodal,  supporting,  for  instance* 

-  A  saealon  level  communication  via  WAN  to  another  FCTE. 

-  An  applicetlon  level  fils  transfer  via  the  IAN  to  e  aainfrana. 

-  A  guest  osar  having  Halted  capability  using  e  mote  coaputer. 


3.9.  Summary  of  dlsltrlbutloa  facilities 

-  PCTE  la  LAN  baaed. 

-  A  PCTE  can  act  aa  If  one  single  machine. 

-  Tha  OHS  database.  Activities,  XFC  and  process  content  are  tranaperently  die* 
tribute! . 

-  Certain  topologies  are  known  and  nans  god  system  wide,  naoaly  workstation*  and 
volumes. 

-  Internal  PCTE  ct— uni  rations  are  ISO  OSI  using,  In  particular,  Esprit  KOSE 
software;  this  ansure*  maxima  portability  of  tha  I'CTE  implementation  across 
a  different  machines. 
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SUMMARY 

PCTE  very'  largely  meets  the  requirements  of  the  RAC.  It  is  especially  strong 
in  the  entity  management  area,  where  it  already  provides  typing  and 
transaction  facilities.  There  are  a  great  many  individual  requirements  in  the 
RAC:  of  these,  only  a  very  few  are  not  addressed  by  PCTE,  and  there  arc  a 
few  more  where  PCTE  only  partially  meets  the  requirements. 

The  two  main  areas  where  PCTE  does  not  meet  the  RAC  are: 

a.  The  need  for  Ada  specifications. 

These  arc  underway. 

b.  Security. 

PCTE’s  security  mechanisms  were  not  designed  with 
DoD  standards  like  CSC-STD-OOl-83  Class  B3  criteria  in 
mind.  A  careful  study  of  this  area  is  needed. 

There  are  a  few  other  aspects,  including: 

a.  PCTE  does  not  support  triggering  (4.2E). 

b.  PCTE  does  not  provide  exact  identities  (4.3A),  although  it  could  be 
extended  to  do  so. 

c.  PCTE  could  only  support  task  waiting  (5.4A)  by  a  mechanism  that  might 
be  uQ&CCcpiabiy  inefficient,  and  wouid  require  modification  to  an  Ada 
RTS  (5.5B). 

There  arc  areas  where  our  study  felt  that  the  RAC  needs 
further  consideration.  It  is  not  obvious  that  any  CAIS 
could  meet  both  requirements  5.4A  and  5.5B. 

d.  PCTE  does  not  fully  provide  the  identification  methods  required  in  4.3C. 

One  should  also  note  that  PCTE,  as  well  as  largely  meeting  the  RAC 
requirements,  also  presents  a  similarity  of  concept  with  CAIS  1  in  most  areas. 
Thus  an  evolution  of  PCTE  could  conceivably  meet  the  CAIS  2  requirement 
of  upwards  compatibility  of  CAIS  1. 
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1.  INTRODUCTION 


1.1  Scope 

This  document  compares  the  DoD  Requirements  and  Design  Criteria  for  the  Common  Ada 1 
Programming  Support  Environment  ( APSE)  Interface  Set  (CAIS)7  (known  as  the  RAC)  to  the 
Portable  Common  Tool  Environment  (PCTE)  Functional  Specifications3.  The  CAIS  and  the 
RAC  are  products  of  the  U.S.  DoD-sponsorcd  KAPSE  Interface  Team  (K.IT),  and  its 
companion  Industry-Academia  team  (KITLA).  The  PCTE  is  a  product  of  the  Commission  of 
the  European  Communities  (CEC)  European  Strategic  Programme  for  Research  and 
Development  in  Information  Technology  (ESPRIT)  program. 

The  RAC  is  a  requirements  document  for  a  CAIS.  While  one  could  define  a  number  of 
different  “CAISes"  which  “comply”  with  the  RAC,  the  U.S.  DoD  intends  to  provide  one 
specific  CAIS  as  a  standard  for  the  DoD  and  its  contractor  community.  There  is  an  initial 
CAIS  known  as  proposed  DoD-STD-CAIS 4;  this  specific  CAIS  is  informally  also  known  as 
CAIS  1:  it  partially  complies  with  the  RAC.  There  is  a  current  contract,  let  by  the  U.S.  Naval 
Ocean  Systems  Center,  to  produce  a  follow-on  product,  known  informally  as  CAIS  2.  CAIS  2 
is  planned  both  to  comply  with  the  RAC  and  to  be  an  upward  compatible  derivative  from 
CAIS  1.  It  is  planned  that  CAIS  2  will  eventually  become  a  U.S.  DoD  Standard,  and  as  such 
be  imposed  on  VS.  Government  agencies  and  their  suppliers. 

There  are  no  plans  to  use  the  R  AC  as  a  generic  template  for  conforming  CAISes;  the  only 
current  purpose  and  raison  d'tire  for  the  RAC  is  to  define  the  requirements  for  the  specific 
CAIS  which  will  eventually  replace  the  proposed  DoD-STD-CAIS  (i.e_  to  define  CAIS  2). 

A  comparison  of  the  RAC  and  PCTE  is  likely  to  yield  some  useful  results.  Firstly,  PCTE 
contains  models  for  some  features  of  the  RAC  which  are  not  defined  in  CAIS  1.  A 
comparison  of  PCTE  and  the  RAC  will  clearly  identify  these  models  and  thus  contribute  to 
the  CAIS  2  design  process.  The  influence  of  these  models  on  CAIS  2  may  facilitate  a 
convergence  of  PCTE  and  CAIS. 


Secondly,  since  a  PCTE  implementation  already  exists,  a  comparison  of  the  RAC  and  PCTE 
yields  information  on  the  implementabiliry  of  RAC  concepts.  This  may  influence  further 
development  of  the  RAC  and  help  to  attain  the  general  design  objective  of  implementability. 


This  document  will  examine  the  conformance  of  the  PCTE  to  the  RAC.  This  requires  some 
assumptions  about  the  spptdiSuwc  cu  uic  rvic  m  a  set  Oi  auu  mtcnaccs  occausc  me  rc  1 1— 
is  currently  defined  only  in  the  C  language. 


In  some  places,  where  it  is  felt  helpful,  specific  comparisons  arc  made  between  the  PCTE  and 
the  CAIS. 


1.2  Terminology 

Precise  and  consistent  use  of  terms  has  been  attempted  throughout  the  document,  by  use  of 
the  nomenclature  and  style  of  the  RAC. 


1.  Ada  it  a  trademark  of  tba  1)4.  Government,  Ada  Joint  Program  Office. 

3.  “DoD  Requirement!  and  Criteria  for  the  Common  Ada  Pro  cramming  Support  Environment  (APSE) 

Interface  Set  (CAIS)1',  prepend  by  the  KIT  tod  K2TIA  for  the  U4.  Government,  Ada  Joint  Program  Office, 
September  IS,  IMS.  Thi*  document  it  in  a  comment  cycle  and  ia  not  an  official  Govvnmant  document. 

3.  "PCTE  A  Bade  for  a  Portable  Common  Tool  Environment,"  Functional  Specification*,  Third  Edition,  Bull  et.  at., 
IMS. 

4.  Military  Standard  Common  APSE  Interface  Set  (CAIS),  U.S.  Government,  Ada  Joint  Program  Office,  SI  January 
IMS,  Propoeed  MIL-STD-CAI5.  Thi*  document  wa*  renamed  *  proposed  DoD  itaodard  to  provide  wider 
applicability,  during  IMS. 
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The  following  verbs  and  verb  phrases  used  by  the  RAC  are  borrowed  and  used  throughout 
the  document  to  indicate  where  and  to  what  degree  individual  constraints  apply.  These 
phrases  arc  used  in  the  Conformance  Requirement  column  of  the  summary  tables  in  the 
following  sections. 

shall  indicates  a  requirement  on  the  corresponding  definition. 

shall  provide  indicates  a  requirement  to  provide  the  prescribed  capabilities. 

shall  support  indicates  a  requirement  to  provide  prescribed  capabilities  or  for  an 
implementation  to  provide  that  capability  constructed  from  other  provided 
interfaces. 

should  indicates  a  desired  goal  but  one  for  which  there  is  no  objective  test 

U  Assumptions  about  PCTE  support  In  Ada 

There  is  a  significant  difference  in  style,  parameterization,  and  error  handling  between  C 
language  system  calls  (e.g_,  as  defined  by  UNIX  and  PCTE),  and  the  way  system  calls  are 
handled  in  Ada  (e.g,  in  the  style  of  the  Ada  Reference  Manual6  and  in  the  style  of  CAIS  1). 
Simple  transliteration  of  the  PCTE  C  interfaces  into  Ada  would  not  result  in  “acceptable” 
Ada  style. 

We  assume  that  PCTE  support  in  Ada  would  be  accomplished  by  translation  into  Ada  style, 
both  in  terms  of  identifiers  (e.g^  meaningful  mnemonics  without  the  7-letter  restriction  of  C), 
in  terms  of  parameters  (c.g^  use  of  appropriate  typing),  and  use  of  exception  conditions  (e.g^ 
instead  of  the  UNIX  error  return  convention).  We  further  assume  use  of  Ada’s  ability  to 
distinguisl  overloaded  subroutine  calls  to  reduce  the  number  of  discrete  PCTE  functions. 

1.4  Assumptions  about  potential  CAIS  2  support  by  PCTE 

One  of  the  pertinent  requirements  on  the  CAIS  2  contractor  is  that  the  new  product  be  (to  the 
greatest  degree  feasible)  upward  compatible  with  CAIS  1.  The  CAIS  2  is  likely  to  depart 
from  CAIS  1  in  its  specification  of  the  RAC-required  features  not  in  CAIS  1;  for  example, 
the  RAC  requires  typed  entity  management  support,  but  does  not  specify  a  model  for  that 
support 

In  those  circumstances  where  PCTE  provides  a  model  for  RAC  feature  implementation  which 
goes  beyond  CAIS  1  (e.g_  typed  entity  management  support),  we  have  made  the  assumption 
that  the  model  is  acceptable,  but  of  course  we  have  no  way  of  predicting  whether  this  model 
will  actually  be  the  one  adopted  in  CAIS  2, 

1_S  Completeness 

For  completeness,  we  have  included  all  the  sections  of  the  RAC,  and  have  inserted  our 
comments  in  an  italic  typeface  following  each  section. 


S.  "Rafaranca  Manual  for  th«  Ada  Programming  Lanjuaja",  AN5I/MIL-STD-181SA,  U.S.  Dapartmant  of 
Dafanaa,  January  1983. 
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2.  GENERAL  DESIGN  OBJECTIVES 


I  Conformaoca  j 

raquiroaant 

RAC  to 

PCTE 

*h»il  provid* 

1,11  ™ 

ihould  provid# 

Y« 

ahkll 

Y«« 

ihould 

M*ytx»  net  (#•«  uxt) 

ihould 

Ym  (libr.  Itval) 

«h»l! 

International 

ihould 

Ym 

■hall  provid# 

Probibly  not  (»•*  uxt) 

2  1  Scop*  of  th«  CAIS  *h*il  provid*  Y«n 

2.3  Buie  S«rvie»»  thovdd  providt  Y«* 

2.3  InrpUnfnubility  «h*ll  Y«* 

2.4  Modularity  «houid  Miyba  net  (»M  Uxt) 

2.5  ExUnwbility  thould  Yu  (libr.  l«v«l) 

2.8  Ttchnoloty  Compatibility  ihtli  InUmAtionxl 

2.7  Uru/onruty  ihould  Y m 

2.8  Security  «h»ltprovid«  Probably  not  (w  Uxt) 

2.1  Scope  of  th*  CA1S. 

The  RAC  requires  that  the  CAIS  shall  provide  interfaces  sufficient  to  support  the  use  of 
APSEs  for  wide  classes  of  projects  throughout  their  lifecycles  and  to  promote  I&T  among 
APSEs. 

PCTE  is  intended  to  serve  for  projects  which  may  span  the  duration  of  the  entire  ESPRIT 
programme  (approximately  10  years  ),  and  its  successors.  It  is  also  intended  for  supporting 
industrial  software  projects,  during  their  entire  life-cycle;  one  can  observe  that  one  of  the  two 
sample  tools  funded  in  the  PCTE  programme  is  a  configuration  management  system.  The  first 
class  of  projects  to  be  supported  are  derived  from  the  ESPRIT  programme  itself,  and  its  five 
mam  thrusts  (advanced  microelectronics,  software  technology,  advanced  information  processing, 
office  automation,  and  flexible  manufacturing ).  Furthermore,  PCTE  goes  beyond  the  needs  of  an 
Ada-only  PSE  (APSE),  since  it  should  support  multiple  languages,  and  multi-language  projects. 

!<xT  has  been  given  substantial  consideration ,  in  particular,  the  schema  mechanisms  and.  the 
multi-level  schema  definition  sets  are  intended  to  guarantee  that  an  entire  subproject  can  be 
moved  to  a  different  environment  without  requiring  a  change  in  the  naming  of  the  objects,  the 
attributes  or  the  links  ( the  lack,  of  adequate  name  space  management  is  one  of  the  major 
deficiencies  of  CAIS  1  m  this  respect). 

2.2  Basie  Services. 

The  RAC  requires  that  the  CAIS  should  provide  simplc-to-usc  mechanisms  for  achieving 
common,  simple  actions.  Features  which  support  needs  of  less  frequently  used  tools  should  be 
given  secondary  consideration. 

Ease  of  use  is  one  of  the  specific  objectives  of  the  PCTE  project  team.  ( It  is  a  matter  of  taste  as 
to  whether  a  particular  set  of  mechanisms  is  simple  or  not.  easy  to  use,  or  not.) 

However,  giving  secondary  considerations  to  "less  frequently  \ used  tools"  is  a  dangerous  policy  for 
which  PCTE  u as  a  different  approach :  it  has  been  frequendy  observed  that  the  "less  frequently" 
used  tools  of  yesterday  have  turned  out  to  be  important  and  popular.  (A  example  outside  the 
traditional  software  engineering  area  is  the  spreadsheet  processor.)  The  PCTE  designers  have 
attempted  to  rely  on  advanced  research  ( eg.,  in  the  application  of  knowledge-based  techniques  to 
the  software  development  area)  to  get  a  feeling  for  which  features  may  turn  out  to  be  important  it: 
the  fi  ture,  and  how  they  can  be  combined  with  today's  needs. 

2-3  luiplemeaUbillty. 

The  RAC  requires  that  the  CAIS  specification  shall  be  machine  independent  and 
implementation  independent.  The  CAIS  shall  be  implcmcntablc  on  bare  machines  and  on 
machines  with  any  of  a  variety  of  operating  systems.  The  CAIS  shall  contain  only  interfaces 
which  pro-idt  facilities  wh;ch  have  been  demonstrated  in  existing  commercial  or  military 
software  systems.  CAIS  features  should  be  chosen  to  have  a  simple  and  efficient 
implementation  in  many  machines,  to  avoid  execution  costs  for  unneeded  generality,  and  to 
ensure  that  unused  portions  of  a  CALS  implementation  will  not  add  to  execution  costs  of  a 
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non-using  tool.  The  measures  o‘-  the  efficiency  criterion  are,  primarily,  minimum  interactive 
response  time  for  APSE  tools  and,  secondarily,  consumption  of  resources. 

The  PCTE  meets  this  objective.  Regarding  efficiency,  an  analysis  of  the  Bull  PCTE  and 
Emeraude  entity  management  support  leads  us  to  believe  its  efficiency  will  be  comparable  to  that 
of  equivalent  UNIX  facilities. 

2.4  Modularity. 

The  RAC  requires  that  interfaces  should  be  partitioned  such  that  the  partitions  may  be 
understood  independently  and  they  contain  no  undocumented  dependencies  between 
partitions. 

PCTE  is  partitioned  in  a  UNIX  style.  There  are  dependencies  between  the  partitions,  particularly 
as  they  relate  to  extending  the  underlying  UNIX  functions  with  distributed  network 
communications,  and  the  entity-relationship  model.  If  the  interfaces  were  respecified  in  Ada.  it 
would  be  possible  to  devise  a  scheme  of  package  structuring  with  fewer  dependencies,  although 
some  dependencies  between  interfaces  are  inevitable  in  an  operating  system.  (See  also  the 
comment  to  section  3.2E.) 

IE  Extensibility. 

The  RAC  requires  that  the  design  of  the  CAIS  should  facilitate  development  and  use  of 
extensions  of  the  CAIS;  Le,  CAIS  interfaces  should  be  reusable  so  that  they  can  be  combined 
to  create  new  interfaces  and  facilities. 

All  PCTE  interfaces  are  program  callable  and  may  therefore  be  extended  using  the  facilities  of 
the  programming  language. 

2.6  Technology  Compatibility. 

The  RAC  requires  that  the  CAIS  shall  adopt  existing  standards  where  applicable.  For 
example  the  RAC  recognizes  standards  by  ANSI,  ISO,  IEEE,  and  DoD. 

PCTE' s  goal  is  conformance  with  applicable  international  ( ISO)  standards.  An  Ada  version  of 
the  PCTE  interfaces  would  also  conform  to  international  standards.  Cenercdly  these  intersect  with 
and  conform  to  the  applicable  ANSI  and  IEEE  standards.  Conformance  with  DoD  standards  is 
unlikely  at  this  time,  because  applicable  DoD  standards  have  not  been  called  out. 

2.7  Uniformity. 

The  KaC  requires  that  the  CAIS  features  should  uniformly  address  aspects  such  as  status 
returns,  exceptional  conditions,  parameter  types,  and  options.  Different  modules  within  the 
CAIS  should  be  specified  to  the  same  logical  level,  and  a  small  number  of  unifying  conceptual 
models  should  underlie  the  CAIS. 

The  PCTE  (C  interfaces)  inherit  the  UNIX  style  of  uniform  treatment  of  status  returns,  signal 
handling,  parameter  types  and  options.  PCTE,  as  a  set  of  Ada  interfaces,  should  meet  the  RAC 
requirement,  but  not  necessarily  in  the  same  manner  as  the  current  C  version  of  PCTE. 

The  main  "conceptual  models "  in  PCTE  are: 

-  objects,  attributes,  and  links, 

•  the  notion  of  schema, 

•  the  notion  of  process  and  "transaction", 

•  the  notion  of  " emissary "  to  implement  distribution,  and 

•  the  un’fied  notion  of  intercommunicating  agents  at  the  user-interface  level. 
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18  Security. 

The  RAC  requires  that  the  CA1S  shall  provide  interfaces  to  allow  tools  to  operate  within  a 
Trusted  Computer  System  (TCS)  that  meets  the  Class  B3  criteria  as  defined  in  The  US.  DoD 
Computer  Security  Center,  Trusted  Conputer  System  Evaluation  Criteria ,  CSC-STD-001-83. 
Specifically; 

a.  It  shall  be  possible  to  implement  the  CAIS  within  a  TCS. 

b.  When  implemented  within  a  TCS,  the  CAIS  shall  support  the  use  of  the  security  facilities 
provided  by  the  Trusted  Computing  Base  (TCB)  to  applications  programs. 

c.  When  not  implemented  within  a  TCS,  the  CAIS  interfaces  sensitive  to  security  shall 
operate  as  a  dt  'icated  secure  system  (Le>,  all  data  at  a  single  security  level,  and  all 
subjects  cleared  to  at  least  that  level). 

The  PCTE  has  not  been  compared  to  the  Class  B3  criteria.  In  general,  its  authors  have  been 
sponsored  to  produce  a  commercial / industrial  product,  and  B3  criteria  may  impose  additional 
requirements. 
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3.  GENEFAL  SYNTAX  AND  SEMANTICS 

3.1  Syntax 


Section 

Confcnzamwa  | 

nvruinKMot 

RAC  to 

PCTE 

3.  LA.  Gtninl  Syntax 

"  ,U*h*il  ' 1 

In  profTftOt 

S.lB  Uniformity 

thould 

In  proem** 

3. 1C  Nun*  Selection 

•hould 

In  prow*** 

3.  ID  Pr*pn«ic» 

•hciuld 

Y*e 

3.1A  General  Syntax.  The  RAC  requires  that  the  syntax  of  the  CAIS  shall  be  expressed  as 
Ada  package  specifications.  The  syntax  of  the  CAIS  shall  conform  to  the  character  set  as 
defined  by  the  Ada  standard  (section  2.1  of  ANSI/MIL-STD-1815A). 

The  Ada  specifications  of  PCTF.  are  in  preparation.  They  will .  no  doubt,  meet  this  requirement. 

3.1B  Uniformity.  The  RAC  requires  that  the  CAIS  should  employ  uniform  syntactic 
conventions  and  should  not  provide  several  notations  for  the  same  concept  CAIS  syntax 
issues  (including,  at  least  limits  on  name  lengths,  abbreviation  styles,  other  naming 
conventions,  relative  ordering  of  input  and  output  parameters,  etc.)  should  be  resolved  in  a 
uniform  and  integrated  manner  for  the  whole  CAIS. 

PCTE's  C  interfaces  retain  compatibility  to  UNIX  interfaces,  because  cf  a  requirement  for  binary 
code  compatibility  to  pre-existing  UNIX  programs .  This  has  caused  several  of  the  “old  style" 
UNIX  interfaces,  which  are  preserved  in  PCTE,  to  provide  a  "duplicate  notation"  to  the  newer  and 
more  robust  PCTE  interfaces.  Additionally,  because  of  the  UNIX-level  requirement  to  keep 
interface  names  generally  shorter  than  seven  characters,  many  awkward  notations  result. 

Furthermore,  the  C  interfaces  with  PCTE  do  not  have  Ada’s  overloaded  names  resolution  facility. 
This  results  in  multiple  notations  for  the  same  service  where  parametric  alternatives  exist. 

A  PCTE  implementation  of  Ada  interfaces,  particularly  if  these  conformed  to  the  CAIS,  would 
resolve  many  of  the  notational  inconsistencies.  An  Ada  interface  could  hide  the  underlying  C- 
named  interfaces  ( though  there  has  been  some  argument  of  adopting  a  different  granularity  in 
PCTE  Ada  vs  PCTE  C  specified  interfaces). 

Given  that  the  translation  of  PCTE’s  C  interfaces  into  Ada  resolves  these  issues  as  assumed  in 
section  13.  then  conformance  is  provided.  If,  however,  the  current  PCTE  interfaces  are  simply 
transliterated,  then  this  RAC  requirement  is  not  met. 

3.1C  Name  Selection.  The  RAC  requires  that  the  CAIS  should  avoid  coining  new  words 
(literals  or  identifiers)  and  should  avoid  using  words  is  an  unconventional  sense.  Ada 
identifiers  (names)  defined  by  the  CAIS  should  be  natural  language  words  or  industry 
accepted  terms  whenever  possible.  The  CAIS  should  define  Ada  identifiers  which  are  visually 
distinct  and  not  easily  confused  (including,  at  least  that  the  CAIS  should  avoid  def  oing  two 
Ada  identifiers  that  are  only  a  2-character  transposition  away  from  being  identical).  The  CAIS 
should  use  the  same  name  everywhere  in  the  interface  set  and  not  its  possible  synonyms, 
when  the  same  meaning  is  intended. 

See  preceding  discussion.  The  PCTE  C  implementation  contains  i  great  deal  cf  unconventional 
words  and  terms,  due  to  conformity  to  the  UNIX  environment.  An  Ada  implementation  (without 
the  requirement  to  have  compatibility  for  preexisting  programs)  is  assumed  to  provide  a  new  set 
of  names  and  terms,  to  use  a  good  Ada  “style". 

3.1D  Pragmatics.  The  RAC  requires  that  the  CAIS  should  impose  only  those  restrictive  rules 
or  constraints  required  to  achieve  I&T.  CAIS  implementors  will  be  required  to  provide  *hc 
complete  specifications  of  all  syntactic  restrictions  imposed  by  their  CAIS  implementations. 
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The  PCTE  meets  this  requirement. 
3.2  Semantics 
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3-2A  General  Semantics.  The  RAC  requires  that  the  CAIS  shall  be  completely  and 
unambiguously  defined.  The  specification  of  semantics  should  be  both  precise  and 
understandable.  The  semantic  specification  of  each  CAIS  interface  shall  include  a  precise 
statement  of  ass  mptions  (including  execution-time  preconditions  for  calls),  effects  on  global 
data  and  packages,  and  interactions  with  other  interfaces. 

The  PCTE  is  defined  as  completely  and  unambiguously  as  CAIS  1. 

'We  feel,  however,  that  an  informal  form  of  specifications,  like  that  adopted  by  PCTE  or  by  CAIS 
1.  cannot  be  adequately  precise.  A  definition  using  some  formal  means  of  description  is  needed, 
at  least  as  guidance  for  implementors. 

There  is  some  reason  to  hope  that  a  formal  definition  of  PCTE  will  be  undertaken  in  the  near 
future. 

3J2B  Responses.  The  RAC  requires  that  the  CAIS  shall  provide  responses  for  all  interface 
calls,  including  informative  non-null  responses  (return  value  or  exception)  for  unsuccessful 
completions.  All  responses  returned  across  CAIS  interfaces  shall  be  defined  in  an 
implementation-independent  manner.  Every  time  a  CAIS  interface  is  called  under  the  same 
circumstances,  it  should  return  the  same  response. 

The  C  version  of  the  PCTE  meets  this  requirement ,  and  any  Ada  versions  most  certainly  would 
too. 

32C  Exceptions.  The  CAIS  interfaces  shall  employ  the  mechanism  of  Ada  exceptions  to 
report  exceptional  situations  that  arise  in  the  execution  of  CAIS  facilities.  The  CAIS 
specification  shall  include  exceptions  (with  visible  declarations)  for  all  situations  that  violate 
the  preconditions  specified  for  the  CAIS  interfaces.  The  CAIS  specification  shall  include 
exceptions  (with  visible  declarations)  that  cover  all  violations  of  implementation-defined 
restrictions. 

In  general,  a  PCTE  Ada  interface,  implemented  as  per  the  assumption  with  good  Ada  style, 
should  meet  this  requirement.  However,  there  are  certain  underlying  UNIX  implementation  issues 
which  might  Teak  through"  to  such  an  implementation.  For  example,  UNIX  permits  excessively 
long  file  and  identifier  names  and  truncates  their  length,  rather  than  providing  the  equivalent  of 
CAIS  Ts  t’sxjSRROR.  This  inconsistency  can  be  resolved  at  the  Ada  library  routine  interface ,  by 
the  incorporation  of  additional  checking. 

3.2D  Consistency.  The  description  of  CAIS  semantics  should  use  the  same  word  or  phrase 
everywhere,  and  not  its  possible  synonyms,  when  the  same  meaning  is  intended. 

A  thorough  analysis  of  PCTE,  in  search  of  violations,  has  not  been  conducted. 

3.2E  Cohesiveness,  Each  CAIS  interface  should  provide  only  one  function. 

This  is  a  goal  which  is  limited  by  the  desired  properties  of  operating  system  implementations. 
Most  kernel  level  functions  provide  multiple  functions,  especially  when  they  effect  the  stored  value 
of  an  object,  a  transaction  status,  and  another  executing  process.  We  believe  that  the  PCTE 
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fmcvonality.  and  accompanying  side  effects,  is  at  least  as  cohesive  as  other  modem  operating 
systems. 

32F  Pragmatics.  The  CAIS  specification  shall  enumerate  all  aspects  of  the  meanings  of  CA1S 
interfaces  and  facilities  which  must  be  defined  by  CAIS  implementors.  CAIS  implementors 
will  be  required  to  provide  the  complete  specifications  for  these  implementation-defined 
semantics. 

PCTE  meets  this  requirement. 
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4.  ENTITY  MANAGEMENT  SUPPORT 
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The  RAC  sretes  that  access  controls  and  security  rights  will  apply  to  all  CATS  facilities 
required  in  this  section. 

PCTE  provides  access  controls  and  security  nights  according  to  a  UNIX  model  ( see  Section  2.8). 

The  RAC  states  that  the  general  requirements  for  the  CAIS  entity  management  support  are 
the  following. 

a.  There  shall  be  a  means  for  retaining  data. 

Provided. 

b.  There  shall  be  a  way  for  retaining  relationships  among  and  properties  of  data. 

Provided. 

c.  There  shall  be  a  way  of  operating  upon  data,  deleting  data,  and  creating  new  data. 
Provided. 

d.  There  shall  be  a  means  for  defining  certain  operations  and  conditions  as  legal,  for 
enforcing  the  definitions,  and  for  accepting  additional  definitions  of  legality. 

Provided. 

c.  There  shall  be  a  means  to  describe  data,  and  there  shall  be  a  means  to  operate  upon  such 
descriptions.  Descriptions  of  the  data  shall  be  distinguished  from  the  data  described. 

Provided. 

f.  There  shall  be  a  way  to  develop  new  data  descriptions  by  inheriting  (some  of)  the 
properties  of  existing  data  descriptions. 

Provided. 

g.  The  relationships  and  properties  of  data  shall  be  separate  from  the  existence  of  the  data 
instances. 

Provided 

h.  The  descriptions  of  data  and  the  instances  of  data  shaJi  be  separate  from  the  tools  that 
operate  upon  theta. 

Provided. 

The  RAC  characterization  (subsections  4.1  -  4.7)  of  Entity  Management  Support  is  based  on 
the  STQNEMAN  requirements  for  a  database,  using  a  model  based  on  the  entity-relationship 
concept  Although  a  CAIS  design  meeting  these  requirements  is  expected  to  demonstrate  the 
characteristics  and  capabilities  reflected  here,  it  is  not  necessary  that  such  a  design  directly 
employ  this  entity-relationship  model. 
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The  RAC  entity-relationship  model,  for  which  definitions  and  requirements  follow  in  4.1  - 
4.7,  fulfills  these  requirements,  and  any  alternative  data  model  shall  fulfill  these  requirements 
and  shall  also  fulfill  the  equivalent  of  the  requirements  in  4. 1  through  4.7. 

4.1  Entities,  Relationships,  and  Attributes. 
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The  following  RAC  definitions,  used  in  this  subsection,  pertain  to  all  the  rest  of  section  4  also: 


entity  a  representation  of  a  person,  place,  event  or  thing. 

relationship  an  ordered  connection  or  association  among  entities.  A  relationship 

among  N  entities  (not  necessarily  distinct)  is  known  as  an  ">  -ary" 
relationship. 


attribute  an  association  of  an  entity  or  relationship  with  an  elementary  value. 

elementary  value  one  of  two  kinds  of  representations  of  data:  interpreted  and 
uninterpreted. 


interpreted  data  a  data  representation  whose  structure  is  controlled  by  CAIS  facilities  and 
may  be  used  in  the  CAIS  operations.  According  to  the  RAC,  exam  Dies 
are  representations  of  integer,  string,  real,  date  and  enumeration  data,  tnd 
aggregates  of  such  data. 

According  to  the  C  definition  of  the  PCTE.  the  four  allowed  representations 
are  integer,  boolean,  date,  or  string. 

uninterpreted  data  a  data  representation  whose  structure  is  not  controlled  by  CAIS  facilities 
and  whose  structure  is  not  used  in  the  CAIS  operations.  Examples  might 
be  representations  of  files,  such  as  requirements  documents,  program 
source  code,  and  program  object  code. 


4.1A  Data.  The  RAC  requires  that  the  CAIS  shall  provide  facilities  for  representing  data 
using  entities,  attributes  or  binary  relationships.  The  CAIS  may  provide  facilities  for  more 
general  N-ary  relationships,  but  it  is  not  required  to  do  so. 


PCTE  provides  these  facilities. 


4.1B  Elementary  Values,  The  RAC  requires  that  the  CAIS  shall  provide  facilities  for 
representing  data  as  elementary  values. 

Provided:  PCTE  provides  both  interpreted  data  ("attributes'')  and  uninterpreted  data  ("files"): 
however,  it  does  not  provide  all  of  the  examples  enumerated  above  or  aggregates  as  interpreted 
data.  Aggregates  could  be  implemented  by  Ada  interfacing  library  routines,  and  then  stored  in 
other  representation  forms.  [ Conformance  is  listed  as  "yes"  because  no  statement  is  made  as  to  a 
precise  list  of  mandatory  representation  forms.] 

4.1C  System  Integrity.  The  CAIS  facilities  shall  ensure  the  integrity  of  the  CAJS-managcd 
data. 
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The  PCTE  appears  to  provide  these  facilities. 

4 2  Typing. 

The  following  RAC  definition,  used  in  this  subsection,  pertains  to  all  the  rest  of  section  4  also: 

typing  an  organization  of  entities,  relationships  and  attributes  in  which  they  are 

partitioned  into  sets,  called  entity  types,  relationship  types  and  attribute 
types,  according  to  designated  type  definitions. 

4.2A  Types,  The  RAC  requires  that  the  facilities  provided  by  the  CAIS  shall  enforce  typing 
by  providing  that  ail  operations  conform  to  the  type  definitions.  Every  entity,  relationship  and 
attribute  shall  have  one  and  only  one  type. 

Provided:  PCTE  has  a  specific  model  of  types. 

•  Entities  of  PCTE  are  typed  in  that  their  partitioning  into  sets  (to  use  RAC  terminology) 
restricts  their  set  of  allowed  attributes  and  their  set  of  allowed  link  types  emanating  from  the 
type  (set  of)  entities.  Every  entity  can  have  only  one  type. 

•  Relationships  of  PCTE  are  also  typed:  this  restricts  their  allowed  set  of  attributes,  the  ( set  of) 
key  attributes,  the  set  of  allowed  destination  entities,  and  the  "anty"  of  the  link.  A  link  may  be 
of  only  one  type. 

•  Attributes  in  the  C  version  of  PCTE  are  typed;  this  restricts  their  value  types,  and  their  initial 
values.  (Attributes  are  applied  to  various  entity  or  relationship  types  in  the  PCTE  model. 
Unlike  CAIS  1.  once  a  given  attribute  is  “ applied "  to  a  relationship  type,  it  exists  for  all 
relationships  of  that  type.  (It  doesn't  occupy  storage,  however ,  if  its  value  is  the  default.) 

In  the  C  version,  the  representation  types  are  limited  to  integer,  boolean,  date,  or  string.  An 
Ada  version  of  PCTE  might  provide  Ada  typing,  and  thus  facilitate  generalized  attribute 
representations,  aggregates  and  the  like. 

In  this  situation,  the  PCTE  provides  a  model  for  meeting  the  RAC  requirements  which  goes 
significantly  beyond  CAIS  1. 

4.2B  Rules  about  Type  Definitions.  The  RAC  requires  that  the  CAIS  type  definitions  shall: 

•  Specify  the  entity  types  and  relationship  types  to  which  each  attribute  type  may  apply. 
PCTE  does  this. 

•  Specify  the  type  or  types  of  entities  that  each  relationship  type  may  connect  and  the 
attribute  types  allowed  for  each  relationship  type. 

PCTE  does  this  by  specifying,  for  an  entity,  the  allowed  emanating  relationships:  for  a 
relationship,  the  allowed  destination  entities;  and  for  each  entity  and  relationship  type,  the 
applied  attribute  types. 

•  Specify  the  set  of  allowable  elementary  values  for  each  attribute  type. 

The  allowable  values  of  these  are  the  basic  types. 

•  Specify  the  relationship  types  and  attribute  types  for  each  entity  type. 

.4r  noted  above,  with  PCTE,  for  each  entity  type,  emanating  relationship  types  are  controlled. 
Destination  relationship  types  are  only  controlled  because  the  relationship  type  itself  restricts 
the  allowed  destinations.  This  model  may  be  slightly  different  from  that  of  the  RAC.  but  we 
assume  it  is  functionally  equivalent. 

PCTE  requires  the  schema  to  specify  which  attribute  types  are  applied  to  each  entity  type. 

•  Permit  relationship  types  that  represent  either  functional  mappings  (one-to-one  or  many- 
to-one)  or  relational  mappings  (one-to-many  or  many-to-many). 
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PCTE  provides  all  of  these  relationship  types. 

•  Permit  multiple  distinct  relationships  among  the  same  entities. 

PCTE  permits  this. 

«  Impose  a  lattice  structure  on  the  types  which  includes  inheritance  of  attributes,  attribute 
value  ranges  (possibly  restricted),  relationships  and  allowed  operations. 

PCTE  only  provides  tree  structures.  See  above  for  attribute  value  range  discussion. 

4.2C  Type  Definition.  The  RAC  requires  that  the  CAIS  shall  provide  facilities  for  defining 
new  entity,  relationship  and  attribute  types. 

PCTE  provides  this. 

4.2D  Changing  Type  Definitions.  The  RAC  requires  that  the  CAIS  shall  provide  facilities  for 
changing  type  definitions.  These  facilities  shall  be  controlled  such  that  data  integrity  is 
maintainecL 

PCTE  meets  this  requirement. 

4.2E  Triggering.  The  RAC  requires  that  the  CAIS  shall  provide  a  conditional  triggering 
mechanism  so  that  prespecified  procedures  or  operations  (such  as  special  validation 
techniques  employing  multiple  attribute  value  checking)  may  be  invoked  whenever  values  of 
indicated  attributes  change.  The  CAIS  shall  provide  facilities  for  defining  such  triggers  and 
the  operations  or  procedures  which  are  to  be  invoked. 

PCTE.  in  the  C  version,  does  not  provide  such  a  faculty.  [We  doubt  that  this  facility  would  be 
provided  by  an  Ada  version  of  PCTE.  either.] 

Implementation  of  triggering  would  require  PCTE  kernel  changes.  A  facility  could  be 
implemented  for  an  enhanced  PCTE  kernel,  where  attribute  triggering  were  supported  by  schema 
entries,  effectively  and  securely  enforced  for  both  Ada  and  non- Ada  usage  of  the  attributes. 

4J  Identification 


The  following  RAC  definitions,  used  in  this  subsection,  pertain  to  all  the  rest  of  section  4  also: 

exact  identity  a  designation  of  an  entity  (or  relationship)  that  is  always  associated  with 
the  entity  (or  relationship)  that  it  designates.  This  exact  identity  will 
always  designate  exactly  the  same  Cuuiy  rcidiiuusiup^,  auu  it  cunnot 
be  changed. 

identification  a  means  of  specifying  the  entities,  relationships  and  attributes  to  be 
operated  on  by  a  designated  operation. 


4JA  Exact  Identities.  The  RAC  requires  that  the  CAIS  shall  provide  exact  identities  for  all 
entities.  The  CAIS  shall  support  exact  identities  for  all  relationships.  The  exact  identity  shall 
be  unique  within  an  instance  of  a  CAIS  implementation,  and  the  CAIS  shall  support  a 
mechanism  for  the  utilization  of  exact  identities  across  all  CAIS  implementations. 


PCTE  does  not  provide  exact  identities  for  the  entities  of  its  object  management  system.  It  would 
not  be  diff  icult  to  modify  PCTE  to  include  such  a  facility;  a  composition  of  the  initial  ivol,  i no. 
and  creation  date  attribute  would  be  sufficient  for  this.  For  relationships  the  exact  identity  could 
be  supported  by  identifying  the  exact  identity  of  the  source  entity  and  the  key  of  the  link.  We  feel 
that  with  such  minor  internal  PCTE  changes,  this  requirement  could  be  fully  met. 


A  particularly  valuable  ability  of  PCTE  is  the  ability  of  PCTE  relationships  to  track  entity 
movement  in  a  distributed  system. 


A  CAIS  2  implementation  superimposed  on  a  PCTE  kernel  could  implement  the  required 
mechanism,  though  it  would  then  not  be  available  to  non- Ada  programs. 
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4JB  Identification.  The  RAC  requires  that  the  CAIS  shall  provide  identification  of  all 
entities,  attributes  and  relationships.  The  CAIS  shall  provide  identification  of  all  entities  by 
their  exact  identity.  The  RAC  requires  that  the  CAIS  shall  support  identification  of  all 
relationships  by  their  exact  identity. 

PCTE  meets  this  requirement  except  in  the  case  of  identification  by  exact  identity. 

4JC  Identification  Methods.  The  RAC  requires  that  the  CAIS  shall  provide  identification  of 
entities  and  relationships  by  at  least  the  following  methods: 

•  Identification  of  some  “start”  cntity(s),  the  specification  of  some  relationship  type  and  the 
specification  of  some  predicate  involving  attributes  or  attribute  types  associated  with  that 
relationship  type  or  with  some  entity  type.  This  method  shall  identify  those  entities  which 
are  related  to  the  identified  start  entity(s)  by  relationships  of  the  given  relationship  type 
and  for  which  the  predicate  is  true.  Subject  to  the  security  constraints  of  section  2.8,  all 
relationships  and  entities  shall  be  capable  of  identification  via  this  method,  and  all 
attributes  and  attribute  types  (except  uninterpreted  data)  shall  be  permitted  in  the 
predicates. 

PCTE  only  allows  those  attributes  defined  to  be  part  of  the  relationship  key  to  be  involved  in 
the  predicate.  Because  this  requirement  specifies  that  a  " predicate ”  permits  any  or  all 
attributes  and  types  to  be  in  a  predicate  expression  (except  uninterpreted  data),  PCTE  does 
not  meet  this. 

This  requirement  could  be  supported  by  an  interpretive  implementation  of  predicate  processing 
in  the  PCTE  kernel,  or  in  a  library  routine  outside  the  kernel.  This  generalized  form  of 
predicate  processing  is  iikely  to  have  performance  limitations  in  any  CAIS  implementation. 

•  Identification  of  an  entity  type  or  relationship  type  and  specification  of  some  predicate  on 
the  value  of  any  attribute  of  the  entity  type  or  relationship  type.  This  method  shall 
identify  those  entities  or  re.’  itionships  of  the  given  type  for  which  the  predicate  is  true. 
Subject  to  the  security  constraints  of  section  2.8,  all  attributes  (except  uninterpreted  data) 
shall  be  permitted  in  the  predicates. 

PCTE  does  not  provide  an  efficient  mechanism  to  support  this  requirement.  It  is  possible, 
however,  to  satisfy  it  by  search  of  the  entire  database.  In  any  CAIS  implementation,  this  is 
likely  to  impose  even  more  severe  performance  problems  than  the  preceding  form  of 
identification. 
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Ye*  (provided) 

4.SB  Tret— etioo  Control 

•hall  (uppari 

Ym  (provided) 

4. SC  Syaeem  i  ailun 

•hall 

Ye* 

-  umin  iniiin  mi 

•hall  (upport 

Ye* 

•hall  support 

Ye* 

1  4.7A  RobuuCi item  It  R«tomion 

Ye*  {with  ceve*ta) 

4.4A  Entity  Operations.  The  RAC  requires  that  the  CAIS  shall  provide  facilities  to: 
*  create  entities 
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•  delete  entities 

•  examine  entities  (by  examining  their  attributes  and  rclationsliips) 

•  modify  endues  (by  modifying  their  attributes) 

•  identify  endues  (as  specified  in  Secdon  4.3) 

Tne  PCTE  meets  this  requirement  with  the  caveat  that  source  identification  methods  of  section  4.3 
cannot  be  supported.  It  should  also  be  noted  that  deletion  of  an  entity  is  achieved  by  deletion  of 
composition  links  to  the  entity,  rather  than  a  single  operation  of  deletion. 

4.4B  Relationship  Operations.  The  RAC  requires  that  the  CAIS  shall  provide  faciliues  to: 

•  create  rclauonships 

•  delete  reladonships 

•  examine  reladonships  (by  examining  their  attributes) 

•  modify  relationships  (by  modifying  their  attributes) 

•  identify  relationships  (as  specified  in  Secdon  4.3) 

The  PCTE  meets  this  requirement  with  the  caveat  that  some  identification  methods  of  section  4.3 
cannot  be  supported. 

4.4 C  Attribute  Operations.  The  RAC  requires  that  the  CAIS  shall  provide  facilities  to: 

•  examiie  attributes 

•  modify  attributes 

The  PCTE  meets  this  requirement. 

4.4D  Exact  Identity  Operations.  The  RAC  requires  that  the  CAIS  shall  provide  facilities  to: 

•  pass  exact  identities  between  processes 

•  compare  exact  identities 

In  the  absence  of  exact  identities  in  PCTE  this  requiremew  in  inapplicable  (see  section  4JA ). 

4.4E  Uninterpreted  Data  Operations.  The  RAC  requires  that  the  CAIS  shall  provide  that  use 
of  the  input output  facilities  of  the  Ada  language  (as  defined  in  Chapter  14  of  ANSI/MIL- 
STD-ioiaA)  results  in  reading/writing  an  uninterpreted  data  attribute  of  an  entity.  The 
facilities  of  Section  6  shall  then  apply. 

The  PCTE  meets  this  requirement  with  the  assumption  that  an  Ada  language  implementation  is 
provided  which  provides  the  Ada  facilities  as  above.  Since  the  uninterpreted  data  attribute  of  an 
entity  is  the  equivalent  of  the  UNIX  “file",  it  should  be  expected  of  Ada  implementations  to  meet 
this  requirement. 

4.4F  Synchronisation.  The  RAC  requires  that  the  CAIS  shall  provide  dynamic  access 
synchronization  mechanisms  to  individual  entities,  relationships  and  attributes. 

The  PCTE  provides  these  features  in  the  Concurrency  and  Integrity  Control  Facilities  functions. 

4.4G  Access  Control.  The  RAC  requires  that  the  CAIS  shall  provide  selective  prohibition  of 
operations  on  entities,  relationships,  and  attributes  being  requested  by  an  individual 

This  requirement  appears  to  imply  discretionary  access  control;  PCTE  defines  access  control 
according  to  a  UNIX  model,  end  does  not  selectively  distinguish  between  access  prohibitions  to 
specific  attributes  and  not  others  for  given  entities  or  relationships.  For  this  reason  the 
compliance  is  noted  as  “partial". 
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CAIS  1  supports  a  somewhat  finer  level  of  access  control.  If  CAIS  2  supports  this  same  level  then 
PCTE  will  require  modification  in  order  to  ensure  convergence.  It  should  be  noted  that  fine 
granule  access  rights  may  have  performance  consequences. 

4.5  Transaction 

The  following  definition,  used  in  this  subsection,  pertains  to  all  the  rest  of  section  4  also: 

transaction  a  grouping  of  operations,  including  a  designated  sequence  of  operations, 

which  requires  that  either  all  of  the  designated  operations  are  applied  or 
none  are;  e.g.,  a  transaction  is  uninterruptible  from  the  user's  point  of 
view. 


4.5 A  Transaction  Mechanism.  The  RAC  requires  that  the  CAIS  shall  support  a  transaction 
mechanism.  The  effect  of  running  transactions  concurrently  shall  be  as  if  the  concurrent 
transactions  were  run  serially. 

Though  only  required  to  "support, "  PCTE  "provides"  this  facility.  In  addition  a  user  can  choose 
the  level  of  transaction  protection. 

4.5B  Transaction  Control.  The  RAC  requires  that  the  CAIS  shall  support  facilities  to  start, 
end  and  abort  transactions.  When  a  transaction  is  aborted,  all  effects  of  the  designated 
sequence  of  operations  shall  be  as  if  the  sequence  were  never  started. 

Though  only  required  to  "support''  PCTE  “ provides ”  this  facility. 

4.5 C  System  Failure.  System  failure  while  a  transaction  is  in  progress  shall  cause  the  effects 
of  the  designated  sequence  of  operations  to  be  as  if  the  sequence  were  never  started. 

PCTE  provides  this  facility.  With  UNIX  a  utility  runs  after  system  failure  to  clean  up  the 
filesystem.  In  PCTE  the  corresponding  utility  also  “undoes''  the  effect  of  partially  completed 
transactions  and  of  transactions  which  completed  but  weren’t  fully  committed  when  the  system 
failed. 


4.6  History 

The  following  RAC  definitions,  used  in  this  subsection,  pertain  to  ail  the  rest  of  section  4  also: 

history  a  recording  of  the  manner  in  which  entities,  relationships  and  attribute  values 

were  produced  and  of  all  information  which  was  relevant  in  the  production  of 
those  entities,  relationships  or  attribute  values. 


4.6A  History  Mechanism.  The  RAC  rcquiics  that  the  CAIS  shall  5Uyyort  a  mechanism  foi 
collecting  and  utilizing  history.  The  history  mechanism  shall  provide  sufficient  information  to 
support  comprehensive  configuration  control. 


PCTE  “ supports "  such  a  mechanism.  It  provides  sufficient  entity  attributes  for  the  mechanism  to 
be  implemented.  There  are  a  large  variety  of  history  mechanisms  implemented  on  UNIX,  and  the 
facilities  they  use  are  provided  by  PCTE. 

4.6B  History  Integrity.  The  RAC  requires  that  the  CAIS  shall  support  mechanisms  for 
ensuring  the  fidelity  of  the  history. 

History  is  stored  as  data  in  PCTE.  General  mechanisms  for  ensuring  the  stability  of  data  are 
provided. 


4.7  Robustness  and  Restoration 


The  following  RAC  definitions,  used  in  this  subsection,  pertain  to  ail  the  rest  of  section  4  also: 

backup  a  redundant  copy  of  some  subset  of  the  CAIS-managcd  data.  The  subset  is 

capable  of  restoration  to  active  use  by  %  CAIS  imph  nentation,  particularly  in 
the  event  of  a  loss  of  completeness  or  integrity  in  the  data  in  use  by 
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implementation. 

archive  a  subset  of  the  CAJS-managed  data  that  has  been  relegated  to  backing  storage 

media  while  retaining  the  integrity,  consistency  and  availability  of  all 
information  in  the  entity  management  system. 

4.7A  Robustness  and  Restoration.  The  RAC  requires  that  the  CAIS  shall  support  facilities 
which  ensure  the  robustness  of  and  ability  to  restore  CAIS-managed  data.  The  facilities  shall 
include  at  least  those  required  to  support  the  backup  and  archiving  capabilities  provided  by 
modem  operating  systems. 

Sackup  could  be  supported  in  a  PCTE  implementation  by  volume  dump  and  restore,  but  this 
might  not  preserve  full  integrity.  It  is  an  open  question  as  to  whether  fully  consistent  backup  can 
be  achieved  in  an  economic  way  in  a  distributed  system  which  allows  disconnection  of 
workstations  in  the  sense  of  PCTE. 

Archiving  is  supported  by  moving  data  to  a  mountable  volume  which  is  then  removed.  This 
preserves  full  consistency  and  integrity  of  the  data. 

PCTE  also  provides  a  variety  of  other  features  which  may  be  used  in  a  similar  way  to  UNIX  to 
provide  analogous  features  to  UNIX,  but  the  means  of  preserving  integrity  are  unclear. 
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5.  FRO  GUAM  EXECUTION  FACILITIES 
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The  RAC  states  that  access  controls  and  security  rights  will  apply  to  ail  CAIS  facilities 
required  by  this  section. 


PCTE  provides  access  controls  on  the  static  context  of  a  program  (eg.,  the  file  storing  the 
executable  code),  but  inherits  the  UNIX  rules  of  access  to  dynamic  contexts  ( the  process 
representation): 

•>  The  "p\"  command  allows  any  user  to  enquire  about  all  other  user's  running  processes  ( cither 
by  exact  identity  or  limited  predicate). 

*  Vic  "kill"  command  allows  any  user  to  enquire  about  the  existence  of  another  running  process 
by  exact  identity  ( FID). 


Therefore,  the  compliance  to  this  requirement  i;  considered  "partial"  for  PCTE. 


PCTE  could  provide  significant  additional  access  control  by  kernel  extension. 


The  following  RAC  definitions  arc  used  in  this  section; 


process 

program 


resource 


activate 


terminate 

drticiivmc 


the  CAIS  facility  used  to  represent  the  execution  of  any  program. 

a  set  of  compilation  units,  one  of  which  is  a  subprogram  called  the  "main 
program.*  Execution  of  the  program  consists  of  execution  of  the  main  rrogram, 
which  may  invoke  subprograms  dcrlaud  in  the  compilation  units  of  the 
program. 

any  capv  ity  which  must  be  scheduled,  assigned,  or  controlled  by  the 
operating  system  to  usuic  ror.sLsicril  and  non-conflicting  usage  by  prog; ants 
unuer  execution.  Examples  of  resources  include:  CPU  time,  memory  space 
(.  ir.uals  imd  virtual),  and  sh  red  facilities  (vsu  iablcs,  devices,  spoolers,  c»c.). 

u  create  a  CAIS  prorcss.  The  activation  of  a  ptogram  bind,  that  program  to 
its  execution  cm  irocmeut,  which  arc  the  resources  required  to  Support  the 
pi o-wii's  execution,  and  includes  the  program  to  be  executed.  The  activation 
of  a  process  marks  the  cirliwst  point  in  lime  which  that  process  can  be 
rcfcioncco  as  an  entity  within  tl  c  CAbS  environment. 

to  stop  the  execution  ol  a  pioccss  such  that  it  cannot  be  tesuined. 

to  remove  >  terminated  p'yccss  so  t’vat  it  may  no  longer  be  rctercoccd  within 
the  CAIS  eavuoument. 
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suspend  to  stop  the  execution  of  a  process  such  that  it  can  resumed.  In  the  context  of 

an  Ada  program  being  executed,  this  implies  the  suspension  of  all  tasks,  and 
the  prevention  of  the  activation  of  any  task  until  the  process  is  resumed.  It 
specifically  docs  not  imply  the  release  of  any  resources  which  a  process  has 
assigned  to  it,  or  which  it  has  acquired,  to  support  its  execution. 

resume  to  resume  the  execution  of  a  suspended  procerts. 

task  wan  delay  of  the  execution  of  t,  task  within  a  process  until  a  CAIS  service 

requested  by  this  task.  h?n  been  performed.  Other  tasks  in  the  same  process  are 
not  delayed. 

5.1  Activation  of  Program 

5.1A  Activation.  The  RAC  requires  tha*  the  CAIS  shall  provide  a  facility  for  a  process  to 
create  a  process  for  a  program  that  has  been  mr.de  ready  for  execution.  This  event  is  called 
activation. 


PCTE  provides  several  facilities  which  accomplish  activation. 


5.1B  Unambiguous  Identification.  The  RAC  requires  that  the  CAIS  'hall  provide  facilities 
for  the  unambiguous  identification  of  a  process  at  any  time  between  its  activation  and 
deactivation;  one  such  capability  ^hall  be  as  an  indivisible  part  o"  activation.  This  act  of 
identification  establishes  a  reference  to  that  process.  Once  such  a  reference  is  established,  that 
reference  will  refer  to  the  same  process  until  the  reference  is  dissolved.  A  reference  is  always 
dissolved  Upon  termination  of  the  process  that  established  the  reference.  A  terminated  piocess 
may  not  be  deactivated  while  there  are  references  to  that  process. 


PCTE  p>  ovides  a  process  identifier  (PB3),  which  is  valid  between  activation  and  deactivation. 
This  meets  the  RAC  requirement. 


CAIS  1  has  a  process  identifier  mode!  closely  integrated  w,th  the  node  identifier  model.  This  is 
quite  different  from  the  PCTE  process  identifier  model.  If.  cs  seems  possible,  the  CAIS  2  model 
is  similar  to  CAIS  1  then  changes  to  PCTE  might  be  needed  to  achieve  convergence. 

5.IC  Activation  Data.  The  RAC  requires  that  the  CAIS  shall  provide  3  facility  to  make  data 
available  to  a  program  upon  its  activation. 


Pf  TP*  nmvirivr  c itrh  n 


5.1D  Dependent  Activation.  The  RAC  requires  that  the  CAIS  shall  provide  a  facility  for  the 
activatiou  of  programs  that  depend  upon  the  activating  process  for  their  existence. 

This  requirement  is  not  precise.  The  following  PCTE  features  appear  to  satisfy  reasonable 
interpretations  of  this  requirement: 


[Note:  In  the  following.  START.  ETW  and  ABORT  indicate  events  which  occur  in  response  to  calling 
specific  PCTE  interface  routines  with  those  (or  similar)  names.] 

In  PCTE. 


a.  selected  processes  can  be  associated  with  an  " activity ”  (which  can  he  considered  a  dynamic 
context  in  which  the  selected  processes  execute );  the  phkcss  which  starts  an  activity  is 
said  to  "act  in  behalf  of  the  activity"  ard  is  an  ancestor  (in  the  UNIX  sense)  of  any  other 
processes  in  the  activity.  When  such  a  "starter"  task  EA.tt  normally  and  when  all  other 
processes  in  the  activity  have  terminated,  then  all  ihc  processes  in  the  activity  are 
deactivated.  When  such  a  "starter"  process  is  ABORTed.  a  signal  u  sem  to  the  other  processes 
in  the  activity  to  encourage  their  termination.  When  all  those  processes  have  terminated, 
then  all  the  processes  in  the  activity  ar>.  deactivated  (Just  as  in  the  "trw  normally"  case). 

b.  processes  not  asseciated  with  an  activity  are  acuvand.  terminated  and  deactivated 
according  to  the  rules  of  UNIX. 
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5. IE  Independent  Activation.  The  RAC  requires  that  the  CAIS  shall  provide  a  facility  for  the 
activation  of  programs  that  do  not  depend  upon  the  activating  process  for  their  existence. 

The  PCTE  appears  to  comply  with  this  requirement.  The  RAC  is  not  precise  here.  It  is  possible 
to  set  up  a  PCTE  child  process  so  that  it  can  continue  after  its  parent  has  been  terminated. 

52  Termination 

5.2A  Termination,  The  RAC  requires  that  the  CAIS  shall  provide  a  facility  for  a  process  to 
terminate  a  process.  There  shall  be  two  forms  of  termination;  the  voluntary  termination  of  a 
process  (termed  completion)  and  the  abnormal  termination  of  a  process.  Completion  of  a 
process  is  always  self-determined,  whereas  abnormal  termination  may  be  initiated  by  other 
processes. 

PCTE  provides  both  of  these  forms  of  termination. 

5.2B  Termination  of  Dependent  Processes,  The  RAC  requires  that  the  CAIS  shall  support 
clear,  consistent  rules  defining  the  termination  behavior  of  processes  dependent  on  a 
terminating  process. 

PCTE  meets  this  requirement.  See  5.JD  and  5.1  E. 

52C  Termination  Data.  The  RAC  requires  that  the  CAIS  shall  provide  a  facility  for 
termination  data  to  be  made  available.  This  data  shall  provide  at  least  an  indication  of  success 
or  failure  for  processes  that  complete.  For  processes  that  terminate  abnormally  the  termination 
data  shall  indicate  abnormal  termination. 

PCTE.  under  normal  circumstances,  only  makes  termination  data  available  to  the  purer, t  of  a 
terminated  but  not  yet  deactivated  process.  The  act  of  reading  this  data  makes  the  process 
deactivated,  which  means  it  is  no  longer  available.  This  is  perhaps  not  in  the  spirit  of  the  RAC. 

5J  Communication 

5.3A  Data  Exchange.  The  RAC  reqwes  that  the  CAIS  shall  provide  a  facility  for  the 
exchange  of  data  among  proccs"C3. 

PCTE  provides  several  such  facilities;  these  include  messages,  pipes,  and  shaied  memory. 

5.4  Synchronization 

5.4A  Task  Waiting.  The  RAC  requires  that  the  CAIS  shall  support  task  waiting. 

Task  waiting  is  not  "provided”  by  PCTE  —  calls  to  the  PCTE  interfaces  cu  e,  in  general,  blocking 
on  the  whole  process.  Task  waiting  could  be  ''supported”  for  a  customer  process  by  interprocess 
communications  to  agent  processes  which  carry  out  the  requested  PCTE  calls  on  behalf  of  the 
customer  process, 

(The  Ada  Run-Time  System  ( RTS )  has  to  be  designed  to  cooperate  with  this  mechanism.) 

I.4B  Parallel  Execution,.  The  RAC  requires  that  the  CAIS  shall  provide  for  the  parallel 
execution  of  processes. 

PCTE  provides  fur  this. 

5.4C  Synchronization,  The  RAC  requires  that  the  CALS  shall  provide  a  facility  for  die 
synchronization  of  cooperating  processes. 

PCl'E  provides  signals,  messages,  waits  and  locks,  which  provide  this  facility. 

5.4D  Suspension,  The  RAC  requires  that  the  CAIS  shall  provide  a  facility  for  suspending  a 
process. 

PCTE  provides  this  facility. 
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5.4E  Resumption.  The  RAC  requires  that  ti  e  CAIS  shall  provide  a  facility  to  resume  a 
process  that  has  been  suspended. 

PCTE  provides  this  facility. 

S3  Monitoring 

S3A  Identity  Reference.  The  RAC  requires  that  the  CAIS  shall  provide  s  facility  for  a 
process  to  determine  an  unambiguous  identity  of  a  process  and  to  reference  that  process  using 
that  identity. 

PCTE  provides  this  facility. 

5-5B  RTS  Independence.  CAJS  program  execution  facilities  shall  be  designed  to  require  no 
additional  functionality  in  the  RTS  from  that  provided  by  Ada  semantics.  Consequently,  the 
implementation  of  the  Ada  RTS  shall  be  independent  of  the  CAIS. 

We  strongly  believe  that  this  requirement  contradicts  with  5.4 A.  the  Task  Waiting  requirement. 

PCTE  intends  to  provide  full  binary  code  cor  ipatibility  with  Standard  UNIX.  This  vould  allovc 
an  Ada  version  of  PCTE  to  support  UNIX-compatible  Ada  compilers  which  have  RTS's 
independent  of  the  CAIS. 

S3C  Instrumentation.  The  RAC  requires  that  the  CAIS  shall  provide  a  facility  for  a  process 
to  inspect  and  modify  the  execution  environment  of  another  process.  This  facility  is  intended 
to  promote  support  for  portable  debuggers  and  other  instrumentation  tools. 

PCTE  provides  this  facility.  It  can,  however  only  be  used  on  processes  which  ere  children  of  the 
inspector  and  modifier  process. 
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6.  1SPUT/0UTPUT 

[This  section  contains  several  answers  based  on  UNIX  knowledge  of  System  III,  extrapolated  to 
assumed  implementation  by  System  V. ] 
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6.2A  Block  Terminal* 

Unknown 

6.3B  T»p*  Drive* 

Unknown 

The  RAC  requires  that  access  controls  and  security  rights  will  apply  to  all  CAIS  facilities 
required  by  this  section. 


The  PCTE  provides  the  same  access  controls  and  security  for  the  devices  specified  in  this  section 
as  it  does  for  entity  managerrutiU  support.  ( See  Section  2.8. J 

The  RAC  states  that  the  requirements  specified  in  this  section  pertain  to  input/output 
between/ among  objects  (e.g,  processes,  data  entities,  communication  devices,  and  storage 
devices)  unless  otherwise  stated.  All  facilities  specified  in  the  following  requirements  arc  to  be 
available  to  non-  privileged  pr  jeesses,  unless  otherwise  specified. 


T“i_  .  r~ii  - ...n  t__ - j  • .  • . • .  .. 
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block  terminal 
consumer 
data  block 

data  unit 
datapath 


a  terminal  that  vransmits/i  eccivei  a  block  of  data  ‘uni  s  at  a  time. 

an  entity  that  is  receiving  data  units  via  a  datapath. 

a  sequence  of  one  or  mo.c  data  units  which  is  treated  as  an  indivisible 
group  by  a  transmission  mechanism. 

a  representation  of  a  v due  of  an  Ada  discrete  type. 

the  mechanism  by  which  data  units  arc  transmitted  from  a  producer  to  a 
consumer. 


sfsitrttfr  /1W1  ^  rl'ltfi  hnitr  flAMiinn  fn  n  1%  s*  t » *  —A  »a 
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the  implementing  mechanism). 

hardcopy  terminal  a  terminal  which  transmits/reccivcs  one  data  unit  at  at  time  and  docs  not 
have  an  addressable  cursor. 


page  terminal 
producer 
terminal 
type-ahead 


a  terminal  which  uansraits/receives  one  data  unit 
an  entity  that  is  transmitting  data  units  via  a  datapath, 
an  interactive  input/output  device. 

the  ability  of  a  producer  to  transmit  data  units  before  the  consumer 
!  equests  the  data  units 


6.1  Virtual  I/O  Devices:  D*U  Unit  1  nuAmbilou 


<.iA  Hardcopy  Terminals.  The  RAC  requires  that  tire  CAIS  shall  provide  interface.;  foi  the 
control  of  hardcopy  terminals. 

IKdTE  provides  fw  conventional  UNIX  supthrt  of  these  devices.  This  mclutles  the  use  of  the 
cutises  and  tehmcaT  facilities,  which  pi  unde  deuce  control  by  subroutine  call.  iau<e>  than  via 
device-specific  da. a  units. 
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6.1B  Prge  Terminals.  The  RAC  requires  that  the  CAIS  shall  provide  interfaces  for  the 
control  of  page  terminals. 

See  6.1  A 

6.1C  Printers.  The  RAC  requires  that  the  CAIS  shall  provide  interfaces  for  the  control  of 
character-imaging  printers  and  bit-map  printers. 

See  6.1  A 

6.1D  Paper  Tape  Drives.  The  RAC  requires  that  the  CAIS  shall  provide  interfaces  for  the 
control  of  paper  tape  drives. 

The  specific  implementation  of  Paper  Tape  Devices  is  not  specified  by  PCTE  or  UNIX.  Common 
practice  is  for  vendors  of  interfaces  and  drivers  to  supply  accompanying  software.  Interfac.es  for 
their  control  typically  rely  on  the  UNIX  “ioctl"  function,  to  avoid  use  of  embedded  datastrenm 
control  sequences. 

6.1F,  Graphics  Support.  The  RAC  requires  that  the  CAIS  shall  support  the  control  of 
interactive  graphical  input/output  devices.  {The  R.AC  appears  to  not  distinguish  between 
graphical  input  devices,  which  usually  are  raster  imaging  devices,  and  locator  devices,  such  as 
mice.  We  presume  the  intent  i,  to  require  locator,  rather  than  raster  imaging,  input.] 

PCTE  defines  an  extensive  set  of  User  Interface  primitives,  which  deal  with  graphical  display 
( output )  devices.  It  also  defines  locator  device  input  primitives. 

6.1F  Telecommunications  Support.  The  RAC  requires  that  the  CAIS  shall  support  a 
tvlccoiniuUujoatiOuS  interface  fur  data,  transmission. 

The  PCTE  functional  description  refers  "ioctl”  (and  associated  commands)  to  the  UNIX  System 
V  description.  These  features  of  UNIX  provide  for  extensive  telecommunications  sttpftorl  for  data 
traumissicn. 


6.2  Virtual  I/O  Devices:  Data  Block  Truumission 

6.2A  Block  Terminals.  The  RAC  requires  that  the  CAIS  shall  provide  interfaces  for  the 
control  of  character-imaging  block  terminals. 


PCTE  support  for  these  devices  L  unknown  at  this  time.  However,  it  is  likely  that  the  interfaces 
provided  by  low  level  input  output  control,  and  by  higher  level  CVttSZ'S  and  TLC,MCAP  facilities 


r f\+t hi  I'ltAar 


.  .... _ _  -L .  f - -  ../  a--— -I- 

yt/  jt4  yf/un  irtvJC  jut  tn j  tjj  ic  rruiniu.). 


iJB  Tape  Drives.  The  RAC  requites  that  the  CAIS  shall  provide  in:ci  faces  foi  the  control  of 
magnetic  tape  drives. 


J CTE  support  for  tape  drives  is  unknown  at  this  time.  However,  it  is  likely  that  the  interfaces 
provided  by  low  Ic jcl  input  output  control,  and  by  UNIX  utilities  provided  in  System  V,  arr 
sufficient  to  meet  this  requirement. 
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6.3  Datapath  Control 


Ssetiou 

Con/aruBscs 

requinsnaat 

HAG  So 

. PCTE _ 

ti.SB  Du»p»th  Timeout 
iS  SC  Evdusive  Aecuu 

lhell  provide 
shall  provide 
shell  provide 

PfiVlAi 

Yea 

6  3D  D&taarefcra  Redirection 

shall  provide 

Y«* 

>3.3E  Datapath  Bi-dTer  Siia 

•nail  provide 

Ye*  ■  to*  tert 

3.37  Datapath  Flushing 

shall  provide 

Yea 

|  6. act  Output.  Datapath  Ptocussp n* 

shah  provide 

Yea 

|  0  3H  Input/CuPsut  Sequaneinj 

shell  provide 

Unknown 

Tlus  section  discusses  RAC  requirements  and  criteria  which  pertain  to  both  data  unit 
transmission  and  block  transmission. 

6„3A  Interface  Level.  The  RAC  requires  that  datapath  control  facilities  of  the  CAIS  shall  be 
provided  at  a  level  comparable  to  that  of  Ada  Reference  Manual’s  File  I/O.  That  is,  control  of 
datapaths  shall  be  provided  via  subprogram  calls  rather  than  via  the  data  units  transmitted  to 
the  device. 

PCTE  provides  the  appropriate  datapath  control  facilities  subroutine  calls,  as  described  below. 

6JB  Timeout.  The  RAC  requires  that  the  CAIS  shall  rrovide  facilities  to  permit  timeout  on 
input  and  ovipv.t  oixiutions. 

KITE  provide:  partial  support  fo>  ’Mis  requirer/utni.  The  "alarm"  function  and  the  ability  to  catch 
it's  sigr.als  can  implement  timeouts;  support  is  listed,  however,  as  partial  because  a  process  may 
have  a  number  of  concurrent  inpit’./ output  opaauons  and  wish  to  implement  timeouts  for  each  of 
them,  and  PCTE  supports  only  cue  alarm  ti.ner  for  a  process.  Thus  a  library  routine 
implementation,  to  schedule  and  arbitrate  in*,  alym's  would  be  required. 

A  CAfS  2  irnplcmcmuiior.  if  it  follows  the  C/'iS  1  nodel  of  providing  on  moult  on  CAIS  calls, 
would  implement  alarm  art  urea  on  within  the  lib  ary  modules  which  interface  the  CAIS  2  to  the 
underlying  PCTE  system. 

6.3C  I  !,Yt’lu.i»vc:  /.ecus.  The  F..AC  requires  that  the  CAIS  shall  provide  facilities  to  obtain 
crcH'sivt  sects*  to  a  produccr/consumcr;  such  exclusive  access  docs  not  prevent  u  privileged 
process  (rom  trair  tfuving  to  the  consumer. 

I'CTE  provides  the  .sow?  level  of  access  restrictions  for  devices  as  it  provides  for  the  entity 
tfiana^emem  facilities.  See  4.4G. 

6 JD  V/atMUr';*®.  Jftdlrtctioo.  The  RAC  requires  that  the  CA.IS  shall  provide  facilities  to 
associate  at  execution  time  the  producer/consurner  of  each  input/output  datastrewu  with  a 
specific  device,  daw  entity,  or  process 

1‘hTE  provides  these  facilities. 

6.3  K  fUtnpath  buffer  Slie,  The  RAC  requires  that  ilic  CAIS  shall  provide  facilities  for  the 
specification  oi  the  sizes  of  input/output  data  path  buffers  during  process  execution. 

I'CTE  allows  specification  of  buffer  sizes  for  "stream"  type  of  input  /output  by  the  inherent 
inclusion  of  UNIX  Sy .tci a  V  library  facilities.  However,  in  general.  UNIX  drivers  perform  in¬ 
ker  act  b  fining  for  non-block  mode  devices  (eg.  TTYs).  In  this  case,  the  user-corn  oiled  sue 
request  dents  not  affect  the  driver's  internally  coded  buffering,  even  though  it  does  r.rAl'.jy 
(tai.de m)  buffering  at  the  level  of  the  UNIX  library  tenure  routines.  Funhcrmo.r.  many 
hardware  implementations  of  serial- port  interfaces  use  microcontrollers  which  pvow.de  yet 
additional  levels  of  buffering,  oho  not  under  so f twiu i  control,  block  mode  device:  generally  art 
implemented  with  DMA  style  transfers,  and  thus  transfer  the  exact  amount  of  data  requeityJ  by 
the  user  (a  the  exact  jc« -tv  size  where  data  mutt  be  spanned  between  or  within  i.it-.h  device 
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physical  sectors;. 

datapath  Hushing.  The  RAC  requires  that  the  CAIS  shall  provide  facilities  for  the 
remo v;il  of  all  buffered  data  from  an  input/ output  datapath. 

Ftt'E  provides  suppnrt  for  this  function,  both  for  streams,  and  for  read  /write  ( toctl)  interfaces. 

6-3  G  Output  Datapsoh  Processing.  The  R.AC  requires  that  the  CAIS  shall  provide  facilities 
to  force  lire  output  of  all  data  in  an  output  datapath. 

FCTE  provides  support  for  this  function,  both  for  streams,  and  for  read /write  (iced)  interfaces. 

6JH  Icput/Outpui  Sequencing.  The  RAC  requires  that  the  CAIS  shall  provide  facilities  to 
ensure  the  servicing  ot  input/output  requests  in  the  order  of  their  invocation. 

PCTE  support  lor  this  requirement  is  unknown. 

6.4  Data  Unit  Transmission 
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6.4A  Data  Unit  Slw.  The  RAC  requires  that  the  CAxS  shall  provide  input/output  facilities 
for  communication  with  devices  requiring  :-bu,  7  -hit,  and  8-bit  data  units,  minimally. 

PCT'f  provides  this  facility. 

0.4BS  Raw  Input/Outnut.  The  R  A  Cl  requires  that  trie  CAIS  ihlll  provide  tire  ability  to 
traasmit/reccivc  data  units  turd  sequence:  of  uni's  without  .ood  fjcaoon.  (Examples  of 
modification  arc  bransfonuatiou  of  uni  (a,  ?ddiuoo  of  units,  and  removal  of  unit-). 

PCTE  p>  ovule;  this  facility. 

i>‘"d  Slngit  Bit/;  Unit  Trr.M3mi.uiou.  The  RAC  «■ -quires  that  the  CAIS  shall  provide 
facilh  :5  for  the  urpiu/outpiit  of  single  data  chits.  The  cotr.plcf'or.  of  this  operation  iuakcj  thr. 
d.Pa  unit  available  to  its  c.oueuivit»{3}  without  jcq.uriDg,  another  input/output  event,  ii'dudi/ig 
die  receipt  o  1  &  termination  or  escape  sequence,  die  jjJl.-pg  of"  boiler,  oi  the  Luvocariou  of  s.ui 
operation  to  force  lupus/ output. 

PCI  li  provides  uii.  facility. 

6  4l>  Padding.  The  RAC  requites  that  the  CMS  shall  specify  the  set  of  data  units  and 
sequences  of  units  (including  the  evil  set)  width  can  be  added  to  in  input/output  daustresm. 
The  CAIb  shah  provide  facilities  pu  mining  a  process  to  iclcr.i/ query  at  cacuuI’uu  time  die 
mbict  Df  dau  uuiu  and  sequence*  of  units  which  may  be  added  (Including  the  uull  sc) 

rCIH.  cu  the  level  of  C  interfaces,  provides  suppm  for  Ul'/h’t  ix'nua  and  'it ,  /u.’h./oij. 

ihese  p'oride  the  required  capability, 
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In  addition,  “ioctl"  in  PCTE  provide :  control  over  delay  times  and  fill  characters. 

6.4E  Filtering.  Tne  RAC  requires  that  the  CAIS  shall  specify  the  set  of  data  units  and 
sequences  of  units  (including  the  null  set)  which  may  be  filtered  from  an  input  or  output 
datastream.  The  CAIS  shall  provide  facilities  permitting  a  process  to  select/ query  at  execution 
time  the  subset  of  data  units  and  sequences  of  units  which  may  be  filtered  (including  the  null 
set). 

The  PCTE  functional  description  refers  "ioctl"  (and  associated  commands)  to  the  UNIX  System 
V  description.  These  features  provide  the  UNIX  implementation  of  these  facilities. 

In  this  situation,  the  PCTE  provides  a  model  for  meeting  the  RAC  requirements  which  goes 
significantly  beyond  CaIS  1. 

6aF  Modification.  The  RAC  requires  that  the  CAIS  shall  specify  the  set  of  modifications 
dial  tan  occur  to  data  units  in  an  input/output  datastream  (e.g.,  mapping  from  lower  case  to 
upper  ease).  The  CAIS  shall  provide  facilities  permitting  a  process  to  selcct/query  at 
execution  rime  the  subset  of  modifications  that  may  occur  (including  the  null  set). 

For  PCTE  discussion,  see  t.4E. 

6.4G  Input  Sampling.  The  RAC  requires  that  the  CAIS  shall  provide  facilities  to  sample  an 
input  datapath  for  available  data  without  having  to  wait  if  data  arc  not  available. 

PCTE,  by  use  of  underlying  UNIX  System  V  facilities,  provides  this  feature. 

6.4H  Transmission  OuM-vtCieristlcs.  The  RAC  requires  that  the  CAIS  shall  support  control  at 
execution  lime  of  host  transmission  characteristics  (e.g_,  rates,  parity,  number  of  bits,  half/fuU 

dimlAv\ 

PCTE,  by  use  of  underlying  UNIX  System  V  facilities,  provides  this  feature.  Also  sec  6  A A. 

6.4 1  Type- Ahead.  The  RAC  requires  that  the  CAIS  snail  provide  facilities  to  disable/enable 
type-ahead.  The  CAIS  shall  provide  facilities  to  indicate  whether  tyye-ahcad  is  supported  in 
the  given  implementation.  The  CAIS  shall  define  the  results  of  invoking  the  facilities  to 
disable/enable  type-ahead  in  those  implementations  that  do  not  support  type-ahead  (e.g_,  nu'i- 
effect  or  exception  raised). 

PCTE,  by  its  use  of  the  UNIX  System  V  driven,  provides  type  ahead,  bi  t  does  not  support  user 
control  of  this  function  ( unless  the  user  weic  to  replace  the  drivers  at  run  time,  which  is  permitted 
by  System  V).  Current  System  V  drivers  do  not  give  the  user  control  over  typeahead,  either  of  its 
enabling  or  of  its  buffeting  size 

6.4,1  Echoing.  The  RAC  requires  that  the  CAIS  shall  provide  facilities  to  disable/enablc 
echoing  of  data  units  to  thcL*  source.  The  CAIS  shall  provide  facilities  to  indicate  whether 
echo-suppression  is  supported  in  tire  given  implementation,  T7ic  CALS  shall  define  rhe  results 
of  invoking  the  facilities  to  disable/enablc  echoing  in  those  implementations  that  do  not 
support  echo-suppression  (e.g.,  null  effect  or  exception  raised). 

For  PCTE  discussion  sec  6.4 E. 

6.4K  Control  Input  DnlashMtm.  The  RAC  requires  that  the  CAIS  shall  provide  facibues  to 
designate  an  input  datasucam  as  a  control  input  data.ru  can ' 

For  PC)  E  discussion,  see  6.4E. 

6.4L  Coutrol  Input  Trap.  The  RAC  requires  that  the  CAIS  iliaU  pioridc  the,  ability  to  abort 
a  process  by  means  of  trapping  a  specific  dou  unit  or  dau  block  in  u  control  input  datnsucarn 
of  drat  proctss. 

Pur  PCTE  discussion,  tec  6.4 1. 
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6.4M  Trap  Sequence.  The  RAC  requires  that  the  CAIS  shall  provide  facilities  to 
specify/query  the  data  unit  or  data  block  that  may  be  trapped.  The  RAC  requires  that  the 
CAIS  shall  provide  facilities  to  disable/enable  this  facility  at  execution  time. 

Far  Pi.TE  discussion,  see  6.4E. 


6.4N  Date  Liuk  Control  The  RAC  requires  that  the  CAIS  shall  support  facilities  for  the 
dynamic  control  of  data  links,  including,  at  least,  self-test,  automatic  dialing,  h&ng-up,  and 
broken-link  handling 

Far  PCTE  discussion,  sse  6.4  E.  (Self-test  is  not  presently  defined  in  the  UNIX  System  V 
description,  but  may  be  implemented  by  a  user-defined  driver.  !n  that  case,  the  ioctl  command 
would  enable  it .) 

6.5  Data  Block  Transmission 


6.5A  Data  Block  Size.  The  RAC  requires  that  the  CAIS  shall  provide  facilities  for  the 
specification  of  the  size  of  a  sequence  of  units  during  program  execution. 

PCTE  provides  two  kinds  of  device  driver  implementations:  character  mode  drivers  and  block 
mode  drivers.  (These  are  provided  by  the  underlying  UNIX  System  V  implementation,  and  are 
user  replaceable.)  Generally,  character  mode  drivers  do  internal  blocking  and  queuing  and  the 
sue  of  a  sequence  of  units  is  a  function  of  system  loading,  data  rates,  memory  available,  and 
driver  implementor  choices.  Block  mode  drivers,  on  the  other  hand,  are  generally  implemented 
such  that  the  block  length  parameter  received  from  the  caller  (user)  governs  the  exact  length  cf 
the  transmission  block. 
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6.6  Data  Entity  Transfer 
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6.6A  Common  External  Form.  The  RAC  requires  that  the  CAI3  shall  specify  a 
representation  on  physical  media  of  a  set  of  related  data  entities  (referred  to  as  the  Common 
External  Form). 


PCTE  relies  on  UNIX  System  V  utilities  (at  least  until  the  PACT  toolset  provides  additional 
utilities).  Al  this  time,  the  UNIX  "tar''  and  “cpio"  functions  do  define  a  common  external  form 
for  data  representation  on  physical  media. 

In  this  situation,  by  virtue  of  using  the  standard  UNIX  utilities.  PCTE  provides  a  model  for 
meeting  ihe  RAC  requirements  which  goes  beyond  CAJS  1. 

6.6B  Transfer.  The  RAC  requires  that  the  CAIS  shall  provide  facilities  using  the  Common 
External  Form  to  support  the  transfer  among  CAIS  implementations  of  sets  of  related  data 
entities  such  that  attributes  and  relationships  arc  preserved. 


PCTE  provides  this  facility  (with  caveat  noted  in  6.6 A ). 


6.7  General  Input/Output 
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synchronous  input/output  operation  to  await  completion. 
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It  is  up  to  the  vendor  of  an  Ada  compiler  (and  run  lime  library )  to  implement  a  specific  model 
for  task  operation.  It  is  expected  that  compiler  vendors  will  provide  sub-scheduling,  within  each 
process,  for  the  active  tasks  in  the  process.  While  PCTE.  by  its  use  of  the  underlying  UNIX  model 
for  input/output,  supports  asynchronous  character-device  transmission,  it  does  not  support 
asynchronous  block  mode  transmission  ( eqp.,  disk  input/output ).  A  compiler  vendor  will  need  to 
resort  to  UNIX's  fork  operation  (or  equivalent)  to  ensure  that  a  process  with  a  task  blocked  on 
input/output  docs  not  impede  the  scheduling  of  other  tasks  for  a  given  process. 


6.7B  Unsupported  Features.  The  RAC  requires  that  the  CAIS  should  provide  facilities  to 
control  the  consequences  when  the  physical  device  does  nor  have  ail  of  the  features  of  the 
virtual  device. 


PCTE.  at  the  level  of  C  interfaces,  provides  support  for  UNIX's  curses  and  TERMCAJP  functions. 
These  provide  this  capability. 
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illgnse^s'-  The  executive  board  meeting  included  B.  Abrams, 
representing  Group  '.  A.  Rudmih..  representing  Group  2.  and  D. 
McGonagie.  This  meeting  was  open  to  KITIA  interested  parties. 

The  executive  ooard  mourns  the  passing  of  H.  Wnlman,  the  cnair 
of  Group  3. 

A  following  meeting  was  held  with  the  above  attendees  and  P. 

Myers  and  P.  Oberndorf  „  to  discuss  the  minutes  of  the  Executive 
Board  meeting,  and  to  explore  solution  avenues  to  the  problems 
raised 

SIRIUS  si  E1IIA:  The  KITIA  has  been,  since  January,  in  a  status 
where  its  original  charter  had  run  out  i i.s. .  members  had 
completing  serving  the  term  of  membership  originally  sought.1. 
Members  had  been  requesting  the  AJ?Q  to  provide  an  official 
statement  of  invitation  to  renew  their  commitment  to  continue  to 
volunteer  service. 

?.  Myers  explained  to  the  general  KIT  meeting  that  KITIA's  and 
its  relationships  with  industry.  The  AJPO  would  no  longer  be 
able  to  sponsor  current  mode  of  operation  and  sponsorship  was  in 
violation  of  several  statutes  governing  BoD  the  KITIA.  It  was 
explained  that  KITIA  members  would  be  welcome  to  continue  to 
attend  KIT  meetings,  but  would  not  receive  official  invitation  or 
be  recognized  officially  as  an  organization. 

The  perceived  notion  by  those  who  heard  Myers'  speach  was  that 
the  KITIA  was  no  longer  in  existence,  but  the  continued 
contributions  by  ex-members  was  sought  ana  aesired  by  the  AJFO , 

There  is  significant  concern  by  KITIA  members  of  three  areas  of 
concerns:  (1)  that  companies  will  not  continue  to  send  members  to 
government  meetings  without  proper  invitation  for  any  number  of 
technicalities.  (2)  that  an  association  between  industry  members 
for  the  purpose  of  providing  opinions  to  the  government  violates 
anti-lobbying  statutes,  and  (3)  that  use  of  government  overheads. 
IRStD  funds,  and  other  similar  funds  to  pay  for 

indurtriai/academic  participation  to  KIT  without  invitation  and 
sanction  may  be  in  violation  of  statutes. 

EXECUTIVE  BOARD  MEETING 

The  following  items  were  discussed  during  the  Executive  Board 
Meeting : 

IX£E£  QZ  2ULE5  HHICB  E1IIA  MISHI  SE  i’lQiAIIES 

&3i.l£lU££  CD  ESSiraiDl  Si  iiass  miss:  Initial  opinion  was  that 
KITIA  members  were  not  acting  m  any  form  of  trust  for  the 
production  of  a  product  which  could  exclude  participation  by  any 
segment  of  industry;  to  the  converse,  their  assembly  was  for  the 
purpose  of  reviewing  and  influencing  a  government  sponsored 
product  wnich  is  an  Interface  Standard. 

lniusiix--£u¥£r;hfflsr;i  iSkbyADa  miss:  A  number  of  rules  govern  the 
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ability  or  industry  memcers  to  meet  with  government  members  ror 
the  purpose  of  influencing  their  decisions.  KITIA's  chartered 
activities  may  be  in  this  category. 

^i'E-  QE  liilEEACIIQtiS  BETWEEN  IUE .  /AC&EEM1A  AiiB  SQYESJiMEIiI 

hi  2Qv§rESSD^  5303221  Isvgi:  :This  is  the  level  at  which  the  E1A 
and  other  "industry  organisations"  usually  operate.!  In  this  form 
of  interaction,  government  managers  ‘.such  as  Jinny  Castor)  would 
provide  items  for  comment  to  industry  and  academia,  and  receive 
their  inputs.  Generally  there  are  several  layers  of  government 
managers  between  the  ones  who  typically  receive  industry  opinion, 
and  the  government  individuals  who  actually  execute  projects. 


hi  U£2ID3Ql£/£2DiI2.j£2I  igvsi:  This  is  the  technical 
level  at  whicr.  the  KITIA  has  been  operating. 


exchange 


SfliCUSSION  CF  §PQN£QB5i3XE  OPPORTUNITIES 


This  approach  basically  involves  the  KITIA's 
pursuing  a  course  of  autonomous  operation.  It  would  involve 
organizational  and  legal  expenses.  It  wouid  set  up  the  KITIA  as 
an  mdustr lal/academic  organization  for  the  purpose  of  technical 
advice  to  NOSC  (or  other  TED  agency). 


llh  'SI  QlflSI  iraas  assssiaiisn) :  The  EIA  has  previously 
expressed  a  willingness  to  sponsor  the  KITIA.  There  has  been 
extensive  discussion  on  this  alternative  in  about  late  1983.  The 
EIA  would  need  to  charge  an  administrative  fee  (about  $3QC  per 
year)  for  representatives  from  "non-member"  organizations.  It 
would  bring  to  bear  a  strong  interface  with  government  managers. 

There  is  concern  that  an  EIA  sponsorship  might  formalize 
industry/ academia  interfaces  at  the  government  manager  level 
■e.g.,  via  Jinny  Castor)  and  that  might  prevent  direct  technical 
exchange  at  tne  lower  levels  of  government  interface  (e.g.,  at 
the  Oberndorf /contractor  levels). 


h‘2Z  1  qi  sthei  eiQf23£l2D3i  Qisaniiaiiaa^ :  The  ACM  currently  has  a 
group  on  the  CAI3.  They  have  once  indicated  a  willingness  to  host 
KITIA  activities.  They  dc  represent  individuals  (as  technical  or 
other  direct  contributors ) ,  rather  than  corporations  and 
institutions  (as  managerial  contributors;. 

There  is  a  concern  that  the  ACM's  currently-established  strongly 
negative  view  toward  the  CAI3  standardization  effort  might  bias 
the  ability  of  the  KITIA  to  adequately  function  in  their 
environment  in  its  current  role. 


EEiiEE  2E  EIIIA  MESSES  CQEIEIBilUCH 

IC512£lflUiai  (IfiEESSSDSiaa  Sfiii):  The  KITIA  members  contribute 
on-the-spot  technical  opinions.  One  view  is  that  they  act  as 
individuals  in  making  these  contributions. 

ESEISSSSIIC.'J  22Q3S3CY  21  323^2013  XnZlllUllQQ-  Most  KITIA  members 
have  oeen  ontributin?  on.  a  technical  luvei,  but  influenced  by 
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t.cair  preset,  department .  or  company  environment.  While 
contributions  are  not  cleared  as  "company  policy",  m  nearly  all 
cases  tr.ey  are  given  with  respect  to  the  KIT  I A  member's 
processional  posture  in  his  organisation, 

£QR£  OF  EXPRESSING  VIEWS  Q£  MEMBERS 

Need  EQ  l£SiEE3lE£  I3EUE£:  Members  feei  a  strong  need  for  their 
inputs  at  KIT  meetings  to  have  some  sort  of  official  sanction. 

Nees  vetusls  IQ  fsiffi  and  £XEI££S  2Qii£Eiiy£  Xiew:  Members  are 
:e.t  to  need  a  forum  for  ]amtly  discussing  industry/ academic 
viewpoints,  and  forming  collective  views. 

Use  a  eq  srsssnd  qq  il££Eiy£  yiew  an  Dflu-aanassiiai  Efiysraipsoi 
*£y£ih  Members  need  the  ability  to  present  collective  views,  and 
to  have  the  collective  views  recognised. 

LIE!  £AIS  HEED  liiDUSIEi/ACACEMIA '  £  CQEIIEUED.  HELZ 

Is  IE  QQ  ils  qwb  I2UI5S •  IS  lEilUSOSS  SElii  CSedsd?  This  is  an 
open  question. 

SISKS  QE  CQKIIIiUEa  IMVQLYEMEIil 

oiSEEIlIiEU  yiEb  ESiSDliai  daiiUES*.  There  is  some  probabilistic 
possibility  that  the  CAIS  will  not  gain  acceptance,  either  for 
political  or  technical  reasons.  Association  with  the  CAIS  at  a 
potential  time  of  failure  can  be  harmful  to  one's  business  or 
career . 
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1.  Introduction. 


Software  quality  assurance  (SQA)  is  a  means  for  program  managers  to  ensure 
the  development  and  life-cycle  maintenance  of  high  quality  computer 
programs.  In  large  scale  embedded  computer  systems  development,  the 
achievment  of  high  quality  software  systems  requires  a  continuance  of 
comprehensive  reviews.  These  reviews  ensure  well  defined  requirements, 
specifications,  design  and  code.  Upon  successful  completion  of  each  review 
cycle,  the  appropriate  products  are  baselined  and  identified  as 
configuration  items  (CD.  The  CIs  are  placed  under  configuration  control 
and  require  formal  procedures  to  implement  any  changes.  The  purpose  of 
strong  configuration  control  is  to  further  ensure  that  the  quality  built  in 
through  top-down  engineering  and  design  is  not  degraded  by  uncontrolled 
changes.  SQA  can  be  visualized  as  a  management  umbrella  under  which  the 
activities  of  configuration  management  (CM)  and  evaluation  and  validation 
( E&V)  are  carried  out.  An  SQA  officer  can  act  as  the  program  manager's 
coordinator  who  maintains  a  system  perspective  of  the  entire  software 
development  and  establishes  a  system  of  independent  checks  and  balances  in 
the  form  of  reviews  and  audits  to  verify  the  quality  at  each  phase  of 
development.  While  it  is  recognized  that  excessive  SQA  activities  can  kill 
any  project  by  stifling  productivity,  too  little  SQA  can  allow  a  poor 
quality  program  tc  be  produced. 

While  not  readily  accepted  by  software  most  engineers,  designers  and 
programmers,  the  implementation  of  management  disciplines  into  a  software 
project  are  as  important  as  the  engineering  disciplines.  Figure  2a  ana  2b 
illustate  the  first  three  to  four  levels  of  a  software  project  component 
structure.  Figures  ^  and  $  expand  the  remaining  components  required  for 
software  evaluation  and  configuration  management  respectively. 

The  resources  to  support  software  engineering  and  management  varies  by 
project/program  and  depends  on  the  following  factors; 

a.  The  size  and  complexity  of  the  development  effort. 

b.  The  development  methodology  implemented. 

c.  The  anticipated  computer  program's  life-cycle. 

d.  Hie  extent  of  the  computer  program's  visibility  and  usage. 

e.  Hie  availability  of  applicable  automated  support  tools  or  systems. 

f.  The  requirements  and  constaints  directed  by  higher  authority. 

g.  The  budgetary  constaints  imposed. 
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Figure  2b.  Software  Project  Component  Structure  (Management/Quality  Assurance) 
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3-  Evaluation  Factor  Concepts, 

The  Evaluation  components  illustrated  in  Figure  4  provide  a  list  of  quality 
factors  and  the  corresponding  evaluation  criteria.  This  concept  is  an 
extension  of  the  quality  factors  and  criteria  established  in  an  Air  Force 
study  which  has  been  republished  by  DOD.  Table  1  provides  definitions  for 
quality  factors;  Table  2  provides  definitions  for  the  related  evaluation 
criteria.  While  there  are  many  other  terms  to  describe  software  quality, 
these  tables  provide  a  good  definitive  list.  Implementing  quality  factors 
allows  a  more  disciplined  approach  to  software  quality  assurance.  The 
software  program  manager  (PM)  is  provided  with  conceptually  simple,  easy  to 
use  terms  for  specifying  required  quality  in  more  precise  manner.  The  PM 
essentially  performs  a  trade-off  analysis  for  the  requirements  of  the 
system.  The  software  developers  are  forced  to  address  how  they  plan  to 
build  the  required  quality  into  the  software.  Specific  software  quality 
attributes  required  are  independent  of  the  design  and  implementation 
techniques  used.  Implementation  of  the  applicable  quality  evaluation 
criteria  provides  the  PM  with  a  quantifiable  criteria  against  which  to  judge 
the  software  quality  prior  to  acceptance  testing  and  operational  use. 

In  establishing  comprehensive  reviews  it  is  necessary  to  go  beyond  the 
basic  quality  factors.  Reviews  must  also  include  operational  and  technical 
evaluation  and  the  conformance  to  applicable  standards.  While  it  usually 
impossible  to  find  a  single  person  capable  of  the  full  comprehensive  review 
of  a  program,  it  is  possible  to  nave  several  people  review  from  his  or  her 
area  of  expertise.  Thus  a  subjective  review  by  a  single  person  becomes  more 
objective  when  reviewed  by  several  people.  Further  refinement  is  possible 
through  implementing  manual  checkoff  lists  or  computer  aided  reports  that 
define  the  applicable  criteria  for  each  product  being  reviewed. 

4.  Summary. 

Providing  quality  software  products  is  accomplished  by: 

a.  Developing  product  quality  through  definitive  statements  of  work. 

b.  Verifying  product  quality  through  comprehensive  reviews. 

c.  Validating  product  quality  through  thorough  testing. 

d.  Maintaining  product  quality  through  stringent  configuration  control. 

Software  quality  assurance  can  contribute  in  the  evaluation  of  the  CAIS  by 
providing  a  definitive  set  of  quality  factors  that  must  be  prioritized  and 
tailored  the  CAIS  needs.  Then  the  applicable  evaluation  criteria  is 
expanded  into  a  definitive  check-list  that  can  be  implemented  manually  or 
automatically  with  computer  aided  tools. 
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!  CRITERIA 


Communication 
i  Commonality 

!  Data  Commonality 


Modularity 


Self- 

Descriptiveness 

Hardware 

Independence 

Software 

Independence 


Compliance 


Technical 

Editing 


Access  Control 


Access  Audit 


Process  Control 


Error  Tolerance 


1  Consistency 


1  Accuracy 


Table  2. 


DEFINITIONS 


Those  attributes  of  the  software  that  provide  the  use 
I  of  standard  protocals  and  interface  routines. 

I 

t 

Those  attributes  of  the  software  that  provide  the  use 
of  standard  data  representation. 

Those  attributes  of  the  software  that  provide  a 
stucture  of  highly  independent  modules. 

Those  attributes  of  the  software  that  provide  explan¬ 
ation  of  the  pmplementation  of  the  function. 

Those  attributes  of  the  software  that  determine  its 
dependency  on  the  hardware  system. 

Those  attributes  of  the  software  that  determine  its 
dependency  on  the  software  environment  (operating 
systems,  utilities,  input/output  routines,  etc.) 

Those  attributes  of  software  evaluation  that  ensure 
all  software  components  conform  to  the  standards  and 
guidelines  imposed. 

Those  attributes  of  software  evaluation  that  ensure 
all  software  documents  conform  to  imposed  style, 
format  and  content  standards  and  are  free  from 
spelling  and  grammarical  errors. 

Those  attributes  of  the  software  that  provide  for 
control  of  the  access  of  software  and  data. 

Those  attributes  of  the  software  that  provide  for  an 
audit  of  the  access  of  software  and  data. 

Those  attributes  of  the  software  that  ensures  the 
security  mechanism  does  not  allow  unauthorized  changes 
to  software  or  data. 

Those  attributes  of  the  software  that  provide  continuity 
of  operation  under  adverse  operating  conditions. 

Those  attributes  of  the  software  that  provide  uniform 

design  and  implementation  techniques  and  notation. 

' 

Those  attributes  of  the  software  that  provide  the 
!  required  precision  in  calculations  and  output. 

I 

I 

Software  Evaluation  Criteria  Definitions 
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1 . . 

!  CRITERIA 
• 

\ 

DEFINITIONS 

i 

i 

!  Execution 

I  Efficiency 

I 

Those  attributes  of  the  software  that  provide  a 
minimum  processing  time. 

1 

!  Storage 
!  Efficiency 

i 

Those  attributes  of  the  software  that  provide  for 
minimum  storage  requirements  during  operation. 

\ 

!  Generality 
• 

1 

1 

Those  attributes  of  the  software  that  provide  breadth 
to  the  functions  performed. 

1 

1  Expandability 

1 

l 

l 

1 

Those  attributes  of  the  software  that  provide  for 
expansion  of  the  data  storage  requirements  or 
computational  functions. 

!  Compliance 

i 

1 

i 

\ 

i 

!  Technical  Editing 

i 

l 

• 

I 

i 

1 

i 

Those  attributes  of  software  evaluation  that  ensure 
all  software  components  (ie:  documents,  code  and 
reports)  conform  to  the  standards  and  guidelines 
imposed. 

Those  attributes  of  software  evaluation  that  ensure 
all  software  documents  conform  to  imposed  style, 
format  and  content  standards  and  are  free  from 
spelling  errors. 

!  Performance 

i 

\ 

1 

» 

Those  attributes  of  soft'  are  that  support  acceptable 
processing  and  response  time. 

Table  2.  Software  Evaluation  Criteria  Definitions 
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